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PREFACE 


The HAL Programming Language has been developed by 
the staff of Intermetrics, Inc. based on many years of exper- 
ience in producing software for aerospace applications . 

HAL accomplishes three significant objectives: 

• increased readcibility , through the use of a 
natural two-dimensional mathematical format; 

• increased reliability, by providing for 
selective recognition of common data and sub- 
routines , and by incorporating specific data- 
protect features ; 

• real-time control facility, by including a 
comprehensive set of real-time control commands 
and signal conditions . 

Although HAL is designed primarily for programming on-bcard 
computers , it is general enough to meet nearly all the needs 
in the production, verification and support of aerospace, and 
other real-time applications . 

The design of HAL exhibits a number of influences, the 
greatest being the syntax of PL/1 and ALGOL, and the two- 
dimensional format of MAC/360 , a language developed at the 
Charles Stark Draper Laboratory. With respect to the latter. 
Intermetrics wishes to acknowledge the fundamental con- 
tribution to the concept and implementation of MAC , made by 
Dr. J. Halcombe Laning of the Draper Laboratory. 

The HAL/S Language Specification was prepared 
by the staff of Intermetrics, Inc. under the direction 
of Dr. Philip Newbold, the document's principal author. 
Contributions were also made by Arra Avakian, Carl 
Helmers , Andy Johnson, Ron Kole, Dan Lickly , Fred 
Martin, Joe Saponaro, and Woody Vandever. 

Editorial assistance was provided by Lee Hotz , 
and the typescript was prepared by the Documentation Department. 
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1. INTRODUCTION 


HAL/S is a programming language developed by 
Intermetrics, Inc,, for the flight software of NASA 
prograuns. HAL/S is intended to satisfy virtually all 
of the flight software requirements of NASA programs. 

To achieve this, HAL/S incorporates a wide range of 
features, including applications-oriented data types and 
organizations, real time control mechanisms, and constructs 
for systems programming tasks. 

As the name indicates , HAL/S is a dialect of the 
original KAL language previously developed by Intermetrics^ 
Changes have been incorporated to simplify syntax, curb 
excessive generality, or facilitate flight code emission. 



1. 1 Pu rpose of the Docu ment. 


This document constitutes the formal HAL/S Language 
Specification, its scope being limited to the essentie^-s of 
HAL/S syntax and semantics. Its purpose is to define 
completely and unambiguously all aspects of the language. 
The Specification is intended to serve as the final arbiter 
in all, questions concerning the HAL/S language. It will be 
the purpose of other documents to give a more informal, 
tutoriiil presentation of the language , and to describe the 
operational aspects of the HAL/S programming system. 


1. 2 Review of the Language. 


HAL/S is a higher order language designed to allow 
programmers, analysts, and engineers to communicate with 
the computer in a form approximating natural mathematical 
expression. Parts of the English language are combined with 
standard notation to provide a tool that readily encourages 
programming without demanding computer hardware expertise. 

HAL/S compilers accept two formats of the source text: 
the usual single line format, and also a multi- line format 
corresponding to the natural notation of ordinary algebra. 
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DATA TYPES AND COMPUTATIONS 


HAL/S provides facilities for manipulating a number 
of different data types. Its integer^ scalar ^ vector, and 
matrix types, together with the appropriate Operators and 
built-in functions, provide an extremely powerful tool for 
the implementation of guidance and control algorithms. Bit 
and character types are also incorporated. 

HAL/S permits the formation of multi-dimensional 
arrays of homogeneous data types, emd of tree**like structures 
which are orgamizations of non^homogeneous data types. 


REAL TIME CONTROL 

HAL/S is a real time control language. Defined blocks 
of code called programs and tasks can be scheduled for 
execution in a variety of different ways. A wide range of 
commands for controlling their execution is also provided, 
including mechanisms for interfacing with external interrupts 
and other environmental conditions. 


ERROR RECOVERY 

HAL/S contains an elaborate run time error recovery 
facility which allows the programmer freedom (within the 
constraints of safety) to define his own error processing 
procedures , or to leave control with the operating system. 


SYSTEM LANGUAGE 

HAL/S contains a number of features especially 
designed to facilitate its application to systems progreunming . 
Thus it substantially eliminates the necessity of using an 
assembler language. 


PROGRAM RELIABILITY 

Program reliability is enhanced when software can, by 
its design, create effective isolation between various 
sections of code, while maintaining ease of access to commonly 
used data. HAL/S is a block oriented language in that blocks 
of code may be estedjlished with locally defined variables that 
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are not visible from outside the block. Separately 
compiled program blocks can be executed together emd 
communicate through one or more centrally m 2 maged and 
highly visible data pools. In a real time environment, 

HAL/S couples these precautions with locking mechanisms 
preventing the uncontrolled usage of sensitive data or areas 
of codu. 


1. 3 Outline of the Document. 

The formal Specification of HAL/S is contained 
in Sections 3 through 10 of this document. Section 2 
introduces the notation to be used in the remainder. 

The global structure of HAL/S is presented in 
Section 3 . Data declaration and referencing are presented 
in Sections 4 and 5, respectively . Section 6 is deypted to 
the formation of different kinds of expressions. Sections 
7 through 10 show how these expressions are variously used 
in executedsle statements . 

Section 7 gives the specification of ordinary 
executable statements such as IF statements, assignments, 
and so on. Section 8 deals with real time programming. 
Section 9 explains the HAL/S error recovery system and 
Section 10 the HAL/S I/O capability. 

Finally, Section 11 is devoted to system language 
features of HAL/S. 


1 
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2. SYNTAX DIAGRAMS AND HAUS PRIMITIVES 


In this Specification, the syntax of the HAL/S 
language is represented in the form of syntax diagrams. 
These are to be read in conjunction with the associated 
sets of semantic rules. Sometimes the semantic 
rules modify or restrict the meaning inherent in the 
syntax diagrams. Together the two provide a complete, 
unambiguous description of the language. The syntax 
diagrams are mutually dependent in that syntactical terms 
referenced in some diagrams are defined in others. There 
are, however,, a basic set of syntactical terms for which no 
definition is given. These are the HAL/S "primitives". 

This Section has two main purposes: to explain how 

to read syntax diagrams, and to provide definitions of the 
HAL/S primitives. Various aspects of HAL source text which 
impact upon the meaning of the diagrams are also discus«’'^d 
briefly. 

A syntax diagram Cross Reference Table may be found 
in Appendix A. 
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2.1 The HAUS Syntax Diagram. 


Syntax diagreuns axe, essentially, flow diagrams 
representing the formal greunmar of a language. By tracing 
the paths on a diagram, various exan^les of the language 
construct it represents may be created. In this Specification, 
the Syntax Diagrams, together with the associated Semantic 
Rules, provide a complete auid uncunbiguous definition of the 
HAL/S Language. The syntax diagreuns are, however, not meant 
to be viewed as constituting a ‘Vorking" greunmar (that is, 
as an analytical tool for compiler construction) . 

A typical exeunple of a syntax diagram xs illustrated 
below. Following the diagram, a set f>f rules for reading 
it correctly is given. The rules apply generally to all 
syntax diagreuns presented in the ensuing Sections. 



2-2 







ORIGINAL PAGE I. 
OE POOR QUALITY 



RULES: 

1. Every diagram defines a syntactical term. The name 

of the term being defined appears in the hexagonal box (p . 
The title of the syntax dia^vram is usually a discursive 
description of the syntacti'^al term. In the case illustra- 
ted, the language construct depicted is a particulariza- 
tion of the syntactical term defined (a ‘"WAIT statement” 
is an example of (^ ) . 

2. To generate seuaples of the construct, the flow path is 
to be followed from left to rights from box to box, 
sj^rting at the point of juncture of the definition box 
(D , and ending when the end of the path is reached. 

3. The path is moved along until it arrives at a black dot 
(^. No "backing up" along points of convergence iuch 
as is allowed . A black dot denotes that a choice of 
paths is to be made. The possible number of divergent 
paths is arbitrary. 

4. Potentially infinite loops such as may sometimes be 
encountered. Sometimes there are semantic restrictions 
upon how many times such loops may be traversed. 

5. Every time a box is encountered, the syntactical term 
it represents is added to the right of the sequence of 
terms generated by moving along the flow path. For 
example, moving along the path paralleling th.e dotted 
line generates the sequence "WAIT <arith exp>;" (see 
Rule 7 . ) 

6. Boxes with squared corners ,such as (9),represent syntactical 
terms defined ^ other diagrams. Boxes with circular 
ends, such as O , represent HAL/S primitives. Circular 
boxes ,such as O ,contain special characters (see 
Section 2.2} . 

7. In the text accompanying the syntax diagrcuns, boxes 
containing lower case names are represent^ by enclosing 
the names in the delimiters <>. Thus box (^becomes 
<arith exp>. Upper case names are reserved words of the 
language. 

8. The example given at ^ is an example of HAL/S code 
which may be generated by applying the syntax diagram 
(since some boxes , such as for example, are defined in 
other syntax diagrams , reference to them may be necessary 
to complete the generative process). 
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2,2 The HAL/S Character Set. 


The HAIi/S character set consists of the 52 ujpper and 
lower case alphabetic: characters, the numerals zero through 
nine, and other symbols. The restricted character set is 
the set necessary for the generation of constructs depicted 
by the syntax diagrams. The extended character set include^ 
in addition ^:ertain other symbols legal in such places as 
comments and character literals, and is used chiefly for the 
purpose of compiler listing annotation. 

The following table gives a complete list of the 
characters in the extended set, with a brief indication of 
their principal usage . 


alphabetic 


alphabetic 


special characters 


literals , 
identifiers 


operators 


identifiers, 
literals , 
reserved words 


pseudo-alphabetic 


[blank) 

( • 
) 


separators 


delimiters 


additional extended-set 
symbols 


identifiers 

literals 


















2.3 HAL/S Primitives, 


HAL/S syntax diagrams ultimately express all syntac- 
tical elements in terms of a small number of special charac- 
ters and pre-defined primitives. Primitives are constructed 
from the characters comprising the HAL/S restricted character 
set. There axe three broad classes of primitives: "reserved 

words", "identifiers", and "literals". 


2.5. 7 RueAvzd (tiofidi 


As their names suggest, reserved words are names 
recognized to have standard meanings within the language 
and which are unavailable for any other use. With the 
exception of %-macro names, they are constructed from 
alphabetic characters alone. Reserved words fall into 
three categories: keywords, %-macro, and built-in function 

names. In the syntax diagreuns, and in the accompanying 
text, reserved words are indicated by upper case characters. 
A list of keywords is given in Appendix B, and of built-in 
function names in Appendix C. 


0 


2.5.2 IdzntiiiiM, 


An identifier is a name assigned^ljy the programmer to 
be a variable, label, or other entity/. Before its attributes 
are defined, it is syntactically known as an <identif ier> . 
Each valid <identifier> must satisfy the following rules: 

e the total number of characters must not exceed 32; 

e the first character must be is^lphabetic ; 

e any cheuracter except the first may be alphabetic 
or nximeric; 

e any character 'except the first or the last may be 
a "break character" (_) . ^ 

The definition of an <identif ier> generally establishes its 
attributes , and particular /Lts type, ^lereaf ter ,because 
its type is known , it is given one of the following syntac- 
tical names, as appropriate: 


<label> 


<process-event name> 
<§ var name> 
<template name> 


where I S 


arith (arit^etic) 

char (character) 

bit 

event 

structure 


The manner in which it's attributes are established is 
discussed in Section 4 . The manner in which it is thereafter 
referenced is discussed in Section 5. 


2.3.3 NumbeAA 


FIXED. 


HAL/S supports three numeric types: INTEGER, SCALAR, and 


INTEGER type provides all the signed integers in some 
finite range. INTEGER DOUBLE supports a larger range than 
INTEGER single. c> 

SCALAR type is represented as floating /i'^oint numbers. As 
such they are an approximation to the signed /teals (engineering 
numbers) within some finite range and with some, finite precision. 
SCALAR DOUBLE supporcs a larger range and/or greater precision 
than SCALAR single. 
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147 


>) 


FIXED type provides an approximation to the reals in the 
range minus one to one with some finite precision. FIXED DOUBLE 
supports a greater precision than FIXED single. FIXEDs are used 
when the computer provides relatively inefficient support for 
SCALARs. y^n general, an engineering number = fraction ♦ scaling. 
For each engineering number the programmer must choose a scaling 
sufficiently large to guarantee that the fraction will always be 
in (-1, 1). When performing calculations involving FIXED types, 
the programmer must manipulate the scalings to main^in precision 
and guarantee that the scaling of the operands are compatible. 

!i 


u 


2.3.4 LLteAjdlA. 

Literals are groups of characters expressing their own 
values. During the execution of a body of HAL code their 
values remain constant. Different rules apply for the forma- 
tion of literals of differing type. 

RULES FOR ARITHMETIC LITERALS: 

1. No distinction is made between integer, scalar, and fixed 
valued literals. They take on either integer, scalar, or 
fixed type according to their context. Similarly, no 
distinction is made between single and double precision. 
Consequently, arithmetic literals can be represented by the 
single syntactical form <number> . 

2. The generic form of a <number> is 

idddddd . dddddddd<exponents> 
where d = decimal digit. 

Any number of decimal digits to an implementation depen- 
dent maximum, including none, may appear before or 
after the decimal point. The sign and decimal point 
are both optional. Any number of <exponents> to an 
implementation dependent maximum may optionally follow, 

3. The form of any of the <exponents> may be: 


B< power > 
E< power > 
H<power> 


- 2<POWer> 
“10<POwer> 
-lg<power> 


where <power> is a signed integer number. The valid 
range of values of <power> is implementation dependent. 


ORiGiNAL PAGE IS 
OF POOR QUAUTY 


4. A literal has an associated scale factor of one 


exampits: 

0.123E16B-3 

45.9 

■4 


RULES FOR BIT LITERALS: 

1. Literals of bit type are denoted syntactically by 
<bit literal>. 

2. They have one of the forms shown below: 

BIN <repetition> 'bbbbbbb' b = binary digit 

OCT <repetition> 'ooooooo' o = octal digit 

where 

HEX <repetition> 'hhhhhhh' h hexadecimal digit 

DEC 'ddddddd* d = decimal digit 

The <repetition> is optional and consists of a parenthesized 
positive integer number- It indicates how many times 
the following string is to be used in creating the value. 

The number of digits lies between 1 and an implementation 
dependent maximcim . 

3. The following abbreviated forms are allowed: 

TRUE S ON = BIN'l' 

FALSE H OFP= BIN' O' 


examples: 

BIN'llOllOOOllO' 

HEX(3)T' 
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RULES FOR CHARACTER LITERALS: , 

{/ ■' 

1. Literals of character type are denoted syntactically 
by <char literal>. 

2. They have one of the two following forms 

' ccccccc ' 

CHAR <repetition> 'ccccccc' 

where c is any character in the HAL/S extended 
character set. The <repetition> consists of a 
parenthesized positive integer literal. It 
indicates hr>!^ many times the following string is 
to be used in creating the value. The number of 
characters lies between zero and an implementation 
dependent maximmn. 

3. A null character literal (zero characters is 

denoted by two adjacent apostrophes. 

4. Since an apostrophe delimits the string of characters 
inside the literal, an apostrophe must be represented 
by two adjacent apostrophes; i.e. the representation 
of "dog's" would be 'DOG"S'. 

5. Within a character literal, a special "escape" 

mechanism may be employed to indicate a character other 
than one in the HAL/S extended character set. is 

defined to be the "escape" character within this context. 

In accordance with an implementation dependent mapping 
scheme, HAL/S characters v/ill be assigned alternate charac- 
ter values. Inclusion of these alternate values in a string 
literal is achieved by preceeding the appropriat;? HAL/S 
character by the proper number of "escape" characters. 

The specified character with the "escape" character (s) 
preceeding it will be interpreted as a single character 
whose value is defined by the implementation. 

Since is used as the "escape" character, specifica- 
tion of the character "<r" as a literal itself must be 
done via the alternate character mechanism, i.e. an 
implementation will designate an alternate value for 
some HAL/S character to be the character 
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2.4 One- and Two-Dimensional Source Formats. 


U 


In preparing HAL source text, either single or multiple 
line format may be used. In the single line or "l-dimensional" 
format, exponents and subscripts are written on the same line 
as the operands to which they refer. In the multiple line or 
"2-dimensional'* format exponents are written above the 
line containing the operands to which they refers and subscripts 
are written below it. Of the two formats, the 2-dimensional 
is regarded as standard since it closely parallels usual 
mathematical practice. 


RULES FOR EXPONENTS: 

1. In the syntax diagrams, the 1-dimensional format is 

assumed for clarity . The operation of taking an exponent 
is denoted by the operator **. 


examples: 

-► A-J 



2. Operations are evaluated right to left (see Section 6.1.1). 

3. If an exponent is subscripted, the subscript must be 
written in the 1-dimensional format. 


RULES FOR SUBSCRIPTS: 

1. In the syntax diagrams, the 2-dimensional format is 
assumed for clarity. Two special symbol® are used to 
denote the descent to a subscript line, and the return 


descent to subscript line 


return from subscript line 


Effectively they delimit the beginning and end of 
a subscript expression^ respectively . 


from it: 

<$> 

<s> 
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2. The 1-dimensionaI format of a siibscript expression 
consists of delimiting it at the beginning by $( and 
at the end by a right parenthesis. 



3 . For certain simple forms of subscript ,the parentheses 
may be omitted. These forms are: 

• a single <number> 


I 

i 


• a single <arith var name> (see Section 5.3) . 



4. If a subscript expression contains an exponentiation 

operation, the latter must be written in the 1-dimensional 
format. 




2. 3 Coniments and Blanks in the Source Text. 


Any HAL source tfxt. consists of sequences of HAL/S 
primitives interspersed with special characters. It is 
obviously of great importance for a compiler to be able to 
tell the end of one text element from the beginning of the 
next. In mk<iy cases the rules for the formation of primitives 
are sufficient to define the boundary . In others, a blank 
character is required as a separator. Blanks ^ure legal in 
the following situations: 

• between two primitives; 

e between two special characters; 

e between a primitive and a special character. 

Blanks are necessary (not just legal) between two primitives. 
With respect to string (bit and character) literals, the single 
quote raark seirves as a legal separator. 

Comments may be imbedded within HAL source text 
wherever blanks are legal. A conunent is delimited at the 
start by the character pair /*, and at the end by the 
character pair */. Any characters in the extended character 
set may app<i^ar in the comment (except, of course, for * 
followed by /) . There are implementation dependent restric- 
tions on the overflow of imbedded comments from line to line 
of the source text. 
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3. HAL/S BLOCK STRUCIURE AND ORGANIZATION 


The largest syntactical unit in the HAL/S language 
is the "unit of compilation". In any implementation, the 
HAL/S compiler accepts "source modules" for translation, 
and emits "object modules" as_A result. Each source module 
consists of one unit of compilation, plus compiler direc- 
tives for its translation. 

At run time, an arbitrary number of object modules are 
combined to form an executable "program complex"^. Generally 
a program complex contains three different types of object 
modules : 

• program modules - characterized by being independ- 

ently executable. 

• external procedure and function modules - charac- 

terized by being callable from other 

modules. 

• compool modules - forming common data pools for 

the program complex. 

Each module originates from a unit of compilation of corres- 
ponding type. 


1 


A program complex is executable within the framework of an 
executive operating system, and a run time utility library. 


3. 1 The Unit of Compilation 


if 


j 


Each unit of compilation consists of a single PROGRAM, 
PROCEDURE, FUNCTION, or COMPOOL block of code, possibly 
preceded by one or more block templates. Templates, in effect, 
provide the code block with information about other code 
blocks with which it will be combined in object module form 
at run time. 

% 

SYNTAX: 



SEMANTIC RULES: ,,, 

1. A program <compilation> is one containing a <program block>. 
Its object module in the program complex may be activated 
by the Real Time Executive (see Section 8,), or by other 
means dependent on the operating system. The <program 
block> is described in Section 3.2. 

2. A procedure or function <compilation> is one containing 
a <procedure block> or <function block>^ respectively . 

Its object module in the program complex is executed by 
being invoked by other program, procedure or function 
modules. Both <procedure block>s and <f unction block>fi 
are described in Section 3.3. 



A compool <compilation> is one containing a <compool block> 
specifying a coininon data pool potentially available to 
any program, procedure or function module in the program 
complex. The <compool block> is described in Section 3.5, 


The code, block in any < compilation> except a compool 
<compilation> may contain references to data in a compool 
<compilation> , references to other < program block>s, and 
invocations of external < procedure block>s or< function 
block>s in other <corapilations>s. A <compilation> making 
such references must precede its code block with a 
block template for each such < program block>, < procedure 
block>, <function block> or <compool block> referenced. 
Block templates are described in Section 3.6. 




omGlMAL ? 
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3.2 The PROGRAM Block. 


The PROGRAM block delimits a main , independently 
executable body of HAL/S code. 


SYNTAX: 


/ program \ 
\ / 

rabCRAM Mock 


% 



ftatamant 

1 


program htadtr 


declart groop 


•xampte: 


task block 


ALPHA: PROGRAM; 
DECLARE Q; 


CALL BETA ASSIGN (Q); 


BETA: PROCEDURE ASSIGN (W); 
DECLARE W; 

W»W-M; 

CLOSE BETA; 


updata block 
- function block 
• procedure block 


CLOSE ALPHA; 


SEMANTIC RULES: 
1. The name of 


The name of the <program block> is given by the <label> 
prefacing the block. 


The <program block> is delimited by a <program header> 
statement at the beginning, and a <closing> at the end. 
These two delimiting statements are described in Sections 
3.7.1 and 3.7.4^ respectively. 


The contents of a <program block> consist of a <declare 
group> used to define data local to the ^program block> , 
followed by any number of executable <statement>s . 











Vi 

4 normal flow of execution of the <statement>s in the 

block is sequential; various types of <statement> may 
modify this normal sequencing in a well-defined way, 

5. PROCEDURE, FUNCTION, TASK, and UPDATE blocks may appear 
nested within a <program block>> The blocks may be 
interspersed between the <statement>s of the <program block>, 
and with the exception of the UPDATE block are not 
executed in-line, 

6. Execution of a <program block> is accomplished by schedul~ 
ing it as a process under the control of the Real Time 
Executive (see Section 8.). 




3.3 PROCEDURE, FUNCTION, and TASK Blocks. 


PROCEDURE, FUNCTION, and TASK blocks share a^ common 
purpose in serving to structure HAL/S code into an interlock- 
ing modular form. The major semantic distinction between the 
three types of block is the manner of their invocation. 


SYNTAX: 



SEMANTIC RULES: 

1. The name of the block is given by the <label> prefacing 
the block. The definition of a block label is considered 
to be in the scope of the outer block containing the 
block in question. Block names must be unique within 
any compilation unit. 

2. The block is delimited at its beginning by a header 
statement characteristic of the type of block, and at the 
end by a <closing>. The delimiting statements are 
described in Sections 3.7.1 through 3.7.4. 

3. The contents of the block consist of a <declare group> 
used ilto declare data local to the block, followed by 
any number of executable <statements>s . 



( 


* 


4. The normal flow of execution of the <statement>s in the 
block is sequential; various types of <statement> may 
modify this normal sequence in a well-defined way. 


5. 


The block may contain further nested PROCEDURE, FUNCTION, 
and UPDAI’E blocks. An UPDATE block may not appear within 
an UPDATE 'block at any level of nesting. The nested blocks 
may appear interspersed between the <statement>s of the 
outer block, and except for the UPDATE block are not 
executed in-lina. A consequence of this rule is that 
PROCEDURE and J^UNCTION blocks may be nested 'Within each 
other to an arbitraiy depth . 


153 


6. Execution of <task blbck> is invoked by scheduling it 

as a process under the control of the Real Time Executive 
(see Section 8) . Execution of a <procedure block> is 
invoked by the CALL statement (see Section 7.4.). Execution 
of a < function block> is invoked by the appearance of its 
name in an expression (see Section 6.4 ) . 

7. A < procedure block> or < function block > may result in 
either a single out-of-line expansion or an in-line expan- 
Sion at each invocation. The semantics of a block invoca- 
tion is independent of the way it is expanded. 

8. A <task block> may not appear within a DO. . .END group. jl50 

9. In the < declare group> of a PROCEDURE of FUNCTION block 
which forms the outermost code block of a < compilation unit> , 
some implementations may require all formal parameters to be 
declared before any local data. 
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3.4 The UPDATE Block. 


The UPDATE block is used to control the sharing of data 
by two or more real time processes. Its functional charac- 
teristics in this respect are described in Section 8. 


SYNTAX: 



SEMANTIC RULES: 

1. If present, the <label> prefacing the <update block> 
“gives the name of the block. If <label> is absent, the 
<update block> is unnamed. 

2 . The block is delimited at its beginning by an <update 
header> statement, and at the end by a <closing>. The 
delimiting statements are described in Sections 3.7.1 
and 3.7.4. 

3. The contents of the block consist of a <declare group> 
used to declare data local to th6 <update block> , 
followed by any number of executcible <statement>s . 

4. The normal flow of execution of the <statement>s in the 
block is sequential; various types of <s tatement> may 
modify this normal Sequencing in a well-defined way . 

5. Only PROCEDURE and FUNCTION blocks may be nested within 
an ^update block>. The nested blocks may appear inter- 
spersed between the <statement>s of the block, and are 
not executed in-line. 


GRlS'S'nL IS 





An <update block> is treated like a <statement> 
in that it is executed in-line. In this respect 
it is different from other code blocks. 

The following <statement>s are expressly forbidden inside 
an <update block> in view of its special protective 
function: 


• I/O statements (see Section 10.) ; 

• invocations of <procedure block>s or <function block>s 
not themselves nested within the <update block>; 

e real-time programming statements, except for the 
SIGNAL, SET, and RESET statements (see Section 8.8). 
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SEMANTIC RULES: 


1. The name of the block is given by the <label> prefacing 
the block. 

2. The block is delimited at its beginning by a <compool 
header> statement, and at its end by a <closing>. The 
delimiting statements are described in Sections 3.7.1 
and 3.7.4. 

3. The contents of the block consist merely of a <declare 
group> used to define the data constituting the compool. 
In no sense is a <compool block> to be regarded as an 
executable body of code. 

The maximum number of <compool block>s existing in a 
program complex is implementation dependent. 
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3.6 Block Templates, 


In a <compilation>, block templates are used to provide 
the outermost code block of the <compilation> with informa- 
tion concerning external code or data blocks. Depending 
upon the implementation, the translation of program, procedure, 
function, and compool <compilation>s may automatically 
generate the corresponding block ten^lates, to be included 
in other <compilation>s by compiler directive. 

g^here are four kinds of block templates, PROGRAM, 
PROCEDURE, FUNCTION, and COMPOOL templates, all being 
syntactically similar (see Section 3.1). 


SYNTAX: 



SEMANTIC RULES: 

1. The <label> of the template constitutes the template 
name. It is the same name as that of the code block to 
which the template corresponds . 

2. The block template is delimited at its beginning, by a 
header statement identical with the header statement of 
the corresponding code block, and at the end by a 
<closing>. The delimiting statements are described in 
Sections 3.7.1 through 3.7.4. 



3. The contents of the block template consist only of a 
<declare group>, which has the following significance: 

• in a <program template>, the <declare group> contains 
no statements. All information about external programs 
is contained in the <progr 2 un header> ; 

• in a <compool template > , the <decl 2 u:e group> is used to 
declare a common data pool identical with that of the 
corresponding <compool block>; ”” 

• in a <procedure template > or <f unction template > , the 
<declare groupTr is used to declare the formal parameters 
of the corresponding <procedure block> or <function 
block> (see Sections 3.7.2 and 3.7.3). 

4 . The keyword EXTERNAL preceding the header statement of 
the block template distinguishes it from an otherwise 
identical code block. To a HAL/S compiler the keyword 
is in effect a {signal to prevent the compiler from 
generating object code for the block and setting aside 
space for the data declared. 
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3.7 Block Delimiting Statements. 


Both code blocks and block templates are delimited 
at the beginning by a header statement characteristic of 
their type, and at the end by a <closing> statement. In 
all code blocks except for the COMFOOL block, the header 
statement is the first statement of the block to be executed 
on entry. A GOMPOOL block, containing only declarations of 
data, is, of course, not executable at all. 
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3.7.1 S^pZ& Heade/L Statem&nts 

Simple header statements are those which specify no 
parcuneters to be passed into or out of the block. v>They 
are the compool, progreun, task and update header state- 
me‘nts . 


SYNTAX: 









o 


SEMANTIC RULES: 

1. The type of the code block or template is detexmined 
by the type of the header statement, which is in turn 
indicated by one of the keywords COMPOOL, PROGRAM, 

TASK and UPDATE, 

2. The keyword ACCESS causes managerial restrictions to 
be placed upon the usage of the block in question. The 
manner of enforcement of the restriction is implements- 
t4.on dependent. 

3. The keyword RIGID causes Compool data (except for 
data with the REMOTE attribute) to be organized in 
the order declared and not rearranged by the compiler. 
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3.7. Z Th^ PAoceduAc HeadeA Statement. 


The procedure header statement delimits the start of 
a <procedure block> or <procedure template>. 


SYNTAX; 


raOCEDURE hNdcr itatMntnt 


proetdiii*' 


REENTRANT 


SEMANTIC RULES: 


The keyv7ord PROCEDURE identifies the start of a <procedure 
block>, or <procedure template> . It is optionally 
followed by lists of "formal parameters" which correspond 
to "arguments" in the invocation of the procedure by a 
CALL statement (see Section 7.4). 


The <identif ier>s in the list following the PROCEDURE 
keyword are called "input parameters" because they may not 
appear in any context inside the code block which may 
cause their values to be changed. 
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3. The <identifier>s in the list following the ASSIGN keyword 
are called "assign parameters" because they may appear 

in contexts inside the code block in which new values may 
be assigned to them. They may, of course, also appear in 
the same contexts as input parameters. 

4. Data declarations for all formal parameters must appear 
in the <declare group> of the <procedure block> or 
<procedure template>. 

5. If the <procedure header> statement specifies neither of 
the keywords REENTRANT or EXCLUSIVE, then only one real 
time process (see Section 8.) may be executing the 
<procedure block> at any one time; however there is no 
enforcing protective mechanism. If the keyword EXCLUSIVE 
is specified, then such a protective mechanism does exist. 
If an EXCLUSIVE <proeedure block> is already being executed 
by a real time process when a second process tries to 
invoke it, the second process is forced into the stall 
state (see Section 8.) until the first has finished execu- 
ting it. If the keyword REENTRANT is specified, then two 
or more processes may execute the <procedure block> 
"simultaneously". 

6. The keyword REENTRAtJT indicates to the compiler that 
reentrancy is desired. However, other attributes and 
conditions may conflict with this overall objective. 

The following effects should be noted: 

• STATIC data is allocated statically and initialized 
statically. There is only one copy of STATIC data 
which must be shared by all processes simultaneously 
executing the block. Hence, in coding REENTRANT 
blocks care must be taken not to assume that STATIC 
variables participate in the reentrancy. 

• AUTOMATIC data is allocated dynamically and initialized 
dynamically. Every process simultaneously executing 
the block gets its own initialized copy of the data 

OP entry into the block. In general, all local data 
in a REENTRANT block should be declared with the 
AUTOMATIC attribute. 

• Procedures and functions defined within a REENTRANT 
block must also possess the REENTRANT attribute if 
they too declare local data which is required to 
participate in the reentrancy. 
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In addition, for reentrancy to be preserved, the following 
rules must be observed: 

• Update blocks* and inline functions within a REENTRANT 
block may not declare any local data, STATIC or 
AUTOMATIC, because the update block does not inherit 
the reentrant attribute from the enclosing procedure 
declaration 

• A procedure or function called by a REENTRANT block 
must itself also be REENTRANT. 

7 , The keyword ACCESS may be attached to the <procedure 

header> of a <procedure template> and its corresponding 
external <procedure block> . It denotes that managerial 
restrictions are to be placed on which <compilation>s 
may reference the <procedure block> . The manner of enforce- 
ment is implementation dependent. 


* Any use of update blocks and LOCK data, or of EXCLUSIVE 
procedure or function blocks should be carefully analyzed 
with respect to unfavorable timing problems if a 
procedure is reentered by a higher priority process. 


3.7.3 The Function HcadeA Statement. 


The function header statement delimits the start of 
a <f unction block> or <function template>. 


SYNTAX; 



SEMANTIC RULES: 

1. The keyword FUNCTION identifies the start of a <function 
block> or <function template> . It is optionally followed 
by a list of "formal parameters" which are substituted 

by corresponding "arguments" in the invocation of the 
<function block> (see section 6.4). 

2. The <identif ier>s in the list following the FUNCTION 
keyword are "input parameters" since they may not appear 
in any context inside the <function block> which may cause 
their values to be changed. 
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Data declarations for all the formal parameters must 
appear in the <declare group> of the <function block> 
or <function template>. 

<type spec> identifies the type of the < function block> 
or <f unction template>. A <function block> may be of 
any type except event. A formal description of the type 
specification given by <type spec> is given in Section 4.7. 

If the <function header> statement specifies neither of 
the keywords REENTRANT or EXCLUSIVE, then only one real 
time process (see Section 8.) may be executing the 
< function block> at any one time; however there is no 
enforcing protective mechanism. If the keyword EXCLUSIVE 
is specified, then such a protective mechanism does exist. 

If an EXCLUSIVE < function block> is already being executed 
by a real time process when a second process tries to 
invoke /JX, the second process is forced into the stall 
state /isee Section 8.) until the first has finished exe- 
cuting it. If the keyword REENTRANT is specified, then 
two or more processes may execute the < function block> 
"simultaneously" . 

The keyv7ord REENTRANT indicates to the compiler that 

reentrancy is desired. However, other attributes and 

conditions may conflict with this overall objective. 

The following effects should be noted; 

• STATIC data is allocated statically ^nd initialized 
statically. There is only one copy of ST/iTIC data 
which must be shared by all processes simultaneously 
executing the block. Hence, in coding REENTRANT 
blocks care must be taken not to assume that STATIC 
variables participate in the reentrancy. 

• AUTOMATIC data is allocated dynamically and initialized 
dynamically. Every process simultaneously executing 
the block gets its cv/n initialized copy of the data 

on entry into the block. In general, all local data 
in a REENTRANT block should be declared with the 
AUTOMATIC attribute. 

• Procedures and functions defined v^ithin a REENTRANT 
block must also possess the REENTRANT attribute if 
they too declare local data which is required to 
participate in the reentrancy. 
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In addition^ for reentrancy to be preserved, the following 
rules must be observed: 

0 Update blocks* and inline functions within a REENTRANT 
block may not declare any local data, STATIC or 
AUTOMATIC, because the update block does not inherit 
the reentrant attribute from the enclosing function 
declaration. 

• A procedure or function called by a REENTRANT block 
m'bst itself also be REENTRANT. 

ii 

7, The keyword ACCESS may be attached to the < function header > 
of a <function template> and its corresponding external 
<function block>. It denotes that managerial restrictions 
are to be placed on which compilation s may reference 
the <function block>. The manrier of enforcement is imple- 
mentation dependent. 


* Any use of update blocks and LOCK data, or of EXCLUSIVE 
procedure or function blocks should be carefully analyzed 
with respect to unfavorable timing problems if a function 
is reentered by a higher priority process. 
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3.7.4 The. CLOSE Statement. 


For all code blocks, COMPOOL blocks, and block templates 
the CLOSE statement Is the <closing> delimiter of the block. 



SEMANTIC RULES : 

1. The <closing> of a code block or block template is 
denoted by the CLOSE keyword followed by an optional 
<label>. If present, <label> must be the name of the 
block. 

2 . Execution of the CLOSE statement causes a normal 
exit from a PROGRAM, PROCEDURE, TASK, or UPDATE 
block, and a run time error from a FUNCTION block. 
Exit from a FUNCTION block must be achieved via 
the RETURN statement (see Section 7.5). 

3. The <closing> of a PROGRAM, PROCEDURE, FUNCTION, 

TASK, or UPDATE block may be labelled as if it were 
a <statement>. The <closing>s of COMPOOL blocks 
and block templates cannot be labelled. 
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3.8 Name Scope Rules. 


By using the code blocks described, and by taking 
advantage of their nesting property, the modularization of 
HAL/S <compilation>s may be effected. An important consequence 
of the nesting property is the need to determine the "neune 
scope" over which names defined in a code block are potentially 
known. Names (i.e. <identifier>s) to which name scope rules 
apply are generally either labels or variable names. 


GENERAL RULES: 

1. The name -scope of a code block encompasses the entire 
contents of the block, including all blocks nested within 
it. 

2. A name defined in a name-scope is known, and therefore 
cible to be referenced, throughout that name-scope, 
including all nested blocks not redefining it. A name 
defined in a name-scope is not known outside that name- 
scope . 

3. Names defined in all common data pools used by a 
<compilation> are considered to be defined in one name- 
scope which encloses the outermost code block of the 
<compilation> . 


QUALIFICATIONS: 

1. The name of a code block is taken to be defined in 
the name scope immediately enclosing the block. A 
PROCEDU^ or FUNCTION label defined at the outermost 
level of compilation can be invoked from anywhere 
within the compilation. 

2. The <label> of a statement is effectively unknown in 
blocks contained in the name scope where the <label> 
is defined. This is because a code block cannot be 
branched out of by using a GO TO statement (see Section 
7.7). 

3. Block labels must be unique throughout a unit of compila- 
tion. 

4. Under particular, limited circumstances described in 
Section 4.3, the names of structure template nodes and 
terminals need not be unique. 
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example: 


outer 

scope 


inner 

scope 



ALPHA: PROGRAM; 
DECLARE X; 
DECURE Y; 


BETA: PROCEDURE;-* 
DECLARE Y; 
DECURE Z; 

CLOSE BETA; 


X knovn everywhere 

this Y known everywhere 
except in 


BETA is known everywhere; 
new Y known in BETA only 
Z known in BETA only 


DELTA: Y - 0; -* 


DELTA not known in BETA 


CLOSE ALPHA; 



4. DATA AND OTHER DECLARATIONS 


The HAL/S language provides a comprehensive set of 
data types. To encourage clarity and decrease the frequency 
of errors of omission, all data is required to be declared in 
specific areas of a HAL compilation called **declare groups*'. 
Occasionally the demands of a particular algorithm also 
reauire other kinds of declarations to be made. The diagram 
on the following page summarizes the relationship among the 
types and organizations. 
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HAL DATA TYPES AND ORGANIZATIONS 


TYPES 


ORGANIZATIONS 


string 


array 


♦ ♦♦ 

structure 


character 


individual 





special 


vector 


event 


vector! 


process 

event 


matrix 


matrix! 


* Component Subscripting (see Section 5.3.5) Allowed. 


** Array Subscripting Allowed. 


*** Structure Subscripting Allowed. 
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4. 1 The Declare Group. 


A <declare group> is a collection of data and other 
declarations. The position of <declare group>s within code 
blocks and block templates has been described in Section 3. 


SYNTAX; 



SEMANTIC RULES; 


1. A <declare group> may simply be empty, or it may contain 
<replace statement>s, <structure template>s, and <declare 
statement>s. The form of each of these constructs is 
defined in this Section. 

2. The "name scope" (see Section 3.8) of <identifier>s 
defined in a <declare group> is the code block contain- 
ing the <declare group> and potentially all code blocks 
nested within it. 
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SEMANTIC RULES: Simple Replacements 

1. A simple replacement is a REPLACE statement with no 
pareuneter list following the <identifier>. 

2. Whenever it is referenced, an <identifier> defined in 
a simple REPLACE statement is to be replaced by <text> 
of the definition as if <text> had been written directly 
instead of the source macro reference. Enclosing the 
reference within ^ signs (e.g. <:ALPHA<:) makes the^ 

<text> visible in the compiler listing. 

3. <text> may consist of any HAL/S characters except 
instances of an unpaired double quote (") character. 

A double quote character (") is indicated within 
<text> by two such characters in succession ("") . 

SEMANTIC RULES: Parametric Replacements 

1. A parametric replacement is defined by a REPLACE statement 

with a list of one or more parameters following the <identifier> . 
The maximum number of parameters allowed is an implementa- 
tion dependent limit. Each parameter is itself a HAL/S 
<identif ier> . It is known only locally to the REPLACE 
statement: its name may therefore be duplicated by 

names used for ether <identifier>s in the name scope 
containing the REPLACE statement. 

2. The <text> of a parametric REPLACE statement is composed of 
any HAL/S characters except instances of an unpaired double 
quote (") character. A double quote character may be 
indicated within <text> by coding two such characters 

in succession. The <text> may contain, but is not 
required to contain, instances of the parameters of 
the REPLACE statement. 



4.2.2 Refje/iencoig REPLACE Statemznt& 
SYNTAX: 



SEMANTIC RULES: 

1. A reference to a parametric REPLACE statement consists 
of the REPLACE ncune followed by a series of <argument>s 
enclosed in parentheses. The REPLACE name must have 
been defined previously within the neime scope of the 
reference. The number of <argument>s must correspond 
to the number of parameters of the REPLACE statement 
being referenced. Enclosing the reference within <: signs 
(e.g., <=CBETA(A,B) <:) make the <text> visible in the compiler 
listing. 

2. The <argument>s supplied in a parametric REPLACE 
reference are substituted for each occurrence of the 
corresponding parameter within the source macro 
definition's <text>. Note that if the parameter in 
question does not occur within the source macro 
definition <text>, the <argument> is ineffective. 

<text> substitution is always completed before parsing. 

Example: 

REPLACE BETA (X, ANGLE) BY "SIN (X ANGLE) - EXP (X)/X"; 


Z = BETA (Y, ALPHA) ; WILL GENERATE SIN(Y ALPHA) - EXP(Y)/y 
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In general, the <argumcnt>s supplied in a parametric 

REPLACE reference comprise <text> separated by commas 

(subject to the specific exceptions listed below) . 

As such, they conform to the preceding semantic rules 

for <text> with the following emendations. 

• Blanks are significant in <argument>s. Only the 
commas used to separate <argument>s are excluded 
from the <text> values substituted into the macro 
definition . 

• The <text> string comprising an <argument> may be 
empty. The value substituted in such a case is a 
null string, 

• Within each <argument> there must be an even number 
of apostrophe characters ( ' ) . The effect of this 
rule is to require that each character literal used 
must be completely contained within a single <argument> 

• Within each <argument> there must be an even number 
of quotation mark characters (") . The effect of this 
rule is to require that the substitution of a nested 
REPLACE statement include the entire text of the 
replacement within a single <argument>. 

• Within each <argument> there must be a balanced number 

of left and right parentheses: fpr each opening left 

parenthesis there must be a corresponding right 
parenthesis. 

• Commas are not separators between <argument>s under the 
following circumstances: 

- within a character literal. 

- within REPLACE <text>. 

- nested within parentheses. 
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4.2.3 IdmtiilzA GzneJiation 


New identifiers may be generated by enclosing a 
reference to a simple REPLACE statement within d signs. 

The effect is to make visible in the compiler listing, 
the catenation of the REPLACE <text> with the characters 
surrounding the construct. For example , REPLACE ABLE BY "BAKER”; 
then : 

1) X = <:ABLE<:YZ 
becomes X = BAKERYZ 

2) CALL P_«ABLE<:(Q,R,S) ; 

becomes CALL P_BAKER (Q,R,S) ; 

d signs are taken in pairs, thus dX<:Y<;:Z<J: is interpreted 
as <:X<?Y<:Zd. 



4.2.4 ldzvvtL(\-Lzn. GzneAotcon UacAo PafioinzteA^ 

New identifiers may be generated for text substitution 
within a source macro text by enclosing references to macro 
parameters within <? signs. The effect is the compile-time 
catenation of the corresponding macro argument with the 
characters surrounding the <?-enclosed parameter (a blank 
is considered as a character). For example; 


REPLACE ABLE(X,Y)BY 
"P = <>X<:QRS+Y; 

CALL SaB_<:Xt ; 

Then the reference ABLE (V, A) causes the 
following substitutions. 

P = VQRS+A; 

CALL SUB V; 


Enclosing the entire reference within ^ signs, i.e.^ <?ABLE (V, A) <r 
makes the text with the new identifiers visible in the 
compiler listing (see Section 4.2.2). 
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4. 3 The Structure Template. 


In HAL/S, a "structure" is a hierarchical organization 
of generally nonhomogeneous data items . Conceptually the 
form of the organization is a "tree", with a "root", 

"branches " , and with the data as "leaves " . The definition of 
the "tree organization" (the manner in which root is connected 
to branches, and branches to leaves) is separate from the 
declaration of a structure having that organization. The 
tree organization is defined by a <structure template> 
described belov;. The description of the declaration of 
structures is deferred to later subsections . 

The following figure illustrates a typical tree 
organization. 


e branches 
es and for 
nor struct 


IftiAL PME 








3* The tree walk" shown can provide an unambiguous linear 
description of the tree organization. The syntactical 
form of the <structure template> corresponding to a tree 
organization calls for the names of minor structures and 
structure terminals to be defined in the same order that 
the tree walk passes them on the left, as indicated by 
the arrow at ♦ in the diagram. 

I. The tree organizations of two templates are considered to 
be equivalent for the purposes of various HAL/S statement 
contexts only if the tree forms are identical, and the type 
and attributes of all nodes in the tree agree. An implication 
of this rule becomes apparent: if two corresponding terminal 
nodes of otherwise equivalent structures reference different 
structure template names , then the structure templates 
containing these terminal nodes are not identical. 

The syntactical form of a <structure template> is now given: 

SYNTAX : 


Structure template statement 


structure 
I template 



STRUCTURE 


identifier 


ALIGNED 


identifier 


attributes 











GENERAL RULES; 


1. The <template name> of the <structure template> is 

given by the <identifier> following the keyword STRUCTURE. 

2. The operational keywords DENSE and ALIGNED denote 

data packing attributes to be applied to all <identifiers> 
declared with the < structure template> . At each level of 
a < structure template>, either the DENSE or ALIGNED 
packing attribute is in effect, subject to modification 
by use of DENSE and ALIGNED as minor <attributes> . The 
choice used in the < structure template> gives the default 
value for the whole template. This packing attribute 
is then inherited from higher to lower levels in the 
structure unless the <attributes>’ of a minor structure 
or terminal element modify the choice. Details of the 
allocation algorithm used for DENSE and ALIGNED data 
are implementation dependent. 

3. The keyword RIGID causes data to be organized in 
the sequential order declared within the < structure 
template>. This attribute is then inherited from 
higher to lower levels in the structure. Details of 
the allocation algorithm used for RIGID are implementa- 
tion dependent. (Note that the absence of the keyword 
RIGID permits compiler reorganization of data) . 

4 . In each def inition^ <number> is a positive integer . 

specifying the level of the tree at which the definition 1 153 

is effective. Numbering is sequential starting with 1 . I 

5. The level of definition in conjunction with the order 
of definition is sufficient to distinguish between a 
minor structure and a structure terminal. 

6 . In the form <identifier><attributes> , <identifier> is 
the name of the minor structure or structure terminal 
defined. The applicable <attributes> are described in 
Section 4.5. 

7. If the <attributes> specify a structure template <type 
speo (see Section 4.7) , then the template of the 
structure is being included as part of the template 
being defined. 

8 . The minor structures and structure terminals of the 
template (and forks and leaves) are sequentially defined 
following the colon. The order of definition has already 
been described. 

9. Each definition of a minor structure or structure 
terminal is separated from the next by a comma. 
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NAME UNIQUENESS RULES: 

1. <template names> may duplicate <identifiers> of any 
other kind within a given name scope, but may not 
duplicate other <template names>. 

2. In ^ given name scope, if a <template name> is used 
exclusively in qualified structure declarations, 
duplications of the <identifiers> used for nodes 
may occur under the following circumstances: 


• Any < identifier> used for a node in one template may 
duplicate an < identifier> used for a node in another 
template . 

• Any < identifier > used for a node in a given template 
may duplicate another <identifier> used for a different 
node in the same template, provided that a qualified 
reference can distinguish the two nodes. 

3. In a given neime scope, if a template is ever used for a 

non-qualified structure varied) le declaration, the duplications 
allowed under rule #2 within that template become illegal. 


exampiei- 

i) definition of a template Z 

STRUCTURE Z: 


r 

1 A SCALAR. X \ . 

1 B VECT0R(4), 

A i 

>n — X / 

1 c. 


A 

2 D MATR1X(4, 4), 


T)J — 2 

2 E BITB); 

ii) definition of a template Y , 

with Z nested within it 


JJ 

STRUCTURE Y: 



1 Fj 

C 

H IP — — 1 t 

2 X Z-STRUCTURE, 

1 


2 6 INTEGER, 


— 2 

1 H CHARACTER (10) j 

A # B # C 

X ^ 


K ^ 


J 

1 

1 

1 

. « 

1 

w 

iii) equivalent form of template 

Y with-jut nesting 

STRUCTURE Y: 


b 

IF, 

2 Xj / \ 

3 A SCALAR, 


r H '9 —1 

3B vector ( 4 ), 

X- 

N. ^ 

3 C, 



4D MATRIX(4,4), // \ - 

4 E BIT(3), 

A B# 

CO 

2 G INTEGER, 


/\ 4 

i H CHARAGTERClO); 

Di 

4 £• 
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4.4 The DECLARE Statement. 


The DECLARE Statement is ^se<3 to declare data names 
and labels, and to define their characteristics or 
<attributes> , 


SYNTAX: 



SEMANTIC RULES: 

1. Each <identifier> and its following <attributes> consti- 
tute the declaration of a data name or label. Each 
definition is separated from the next by a comma. 

2. The generic characteristics if any, of all <identifier>s 
to be declared are given by the "factored" <attributes> 
immediately following the keyword DECLARE. The 
<attributes> of a particular <identifier> must not 
conflict with the factored <attributes> . 

3. The name scope of any of the <identif ier>s defined in a 
<declare statement> is the code block containing the 
<declare group> of which the <declare statement> is a 
part (see Section 3.8). In any name scope all such 

< identifiers > must be unique. 

4. There are two forms of <attributes> ; data declarative, and 
label declarative. The form determines whether an 
<identifier> is defined as a data name or a label. 


4-14 
















GENERAL SEMANTIC RULES; 

1. The <type speo determines the type and possibly the 
precision of the <identifier> to which the <attributes> 
are attached. Type specifications are discussed in 
Section 4.7. 

2. An optional array specification can precede the <type 
speo. It starts '-with the keyword ARRAY; the following 
parenthesized list specifies the number of dimensions 

in the array, and the size of each dimension. The number N 
of <arith exp>s gives the number of dimensions of the array. 
<arith exp> is an unarrayed integer or scalar expression 
computable at compile time^. The value is rounded to the 
nearest integer, and indicates the number of elements in a 
dimension. Its value must lie between 2 and an 
implementation-dependent maximum. The maximum value of N 
is implementation dependent. A single asterisk denotes 
a linear array, the number of elements of which is greater 
than 1 but unknown at compile time. 

3. Following the <type speo a number of minor attributes 
applicable to the <identifier> can appear. These are: 

• STATIC/AUTOMATIC - the appearance 'of one of these key- 
words is mutually exclusive of the other, STATIC and 
AUTOMATIC refer to modes of initialization of an 
<identif ier> , not to the allocation of its storage- 
The AUTOMATIC attribute causes an <identifier> with 
the <initialization> attribute to be initialized on 
every entry into the code block containing its 
declaration. The STATIC attribute causes such an 
<identifier> to be initialized only on the first 
entry into the code block. Thereafter its value on 
any exit from the code block is guaranteed to be 
preserved for the next entry into the block. STATIC 
data is not reinitialized whenever a program is re- 
entered (executed again) . Vdlues are preserved in 
this way even though a STATIC <identifier> has no 
<initialization> . Preservation of values is not 
guaranteed for AUTOMATIC <ldentif ier>s . If ne^.ther 
keyword appears, then STATIC is assumed. 


U 



^ See Appendix F. 
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DENSE/ALIGNED *• The appearance of one of these keywords 
is mutually exclusive of the other. Although legal 
in other contexts, the keywords are only effective 
when appearing as <attributes> in a <structure template>. 
DENSE and ALIGNED refer to the storage packing density 
to be employed when a <structure var name> is declared 
using the template. If neither keyword appears, then 
ALIGNED is ass\imed. 

ACCESS - This attribute causes implementation 
dependent managerial restrictions to be placed 
upon the usage of the <identifier> as a variable 
in assignment contexts. The manner of enforce’- 
ment of the restrictions is implementation 
dependent. 

LOCK - This attribute caurses use of the <identifier> 
to be restricted to the interior of UPDATE blocks, 
and to assign argument lists. <number> indicates 
the "lock group" of the <identifier> and lies 
between 1 and an implementation-dependent maximum. 

"*" indicates the set of all lock groups. Specifying 
LOCK (*) for a formal parameter overrides the LOCK 
attribute (if any) of the corresponding argument in 
the invocation. The purpose of the attribute is de- 
scribed in Section 8.10. 

LATCHED - see Section 4.7. 

■<initialization> - This attribute describes the 
manner in which the values of an <identifier> 
are to be initialized. It is descr.iJaed in 
Section 4.8. 

REMOTE - This attribute identifies data which is 
to be located in areas separate from normal data. 

Its implementation is machine dependent. Its 
purpose is to provide information to the compiler so 
that proper addressing to the data can be generated. 
Generally, this addressing requires longer and slower 
access methods. REMOTE data cannot be AUTOMATIC. 

RIGID - Although legal on other contexts, the keyword 
is only effective when appearing as an <attribtue> 
in a <structure template> or in a Compool. It causes 
data to be organized in the order it is defined within 
the <structure templates . 



• RANGE - This attribute is used to specify the range I j 

of values of the variable. If only one <arith exp> ^ 

is specified, it must be greater than zero and the 
specification is equivalent to a RANGE (-<arith exp> 

TO <arith exp>). <arith exp> is an unarrayed integer 
or scalar expression computable at compile time. 1 
<arith exp>^ must be less than <arith exp> 2 « 

- For INTEGERS, the <arith exp>s are converted to 
integers2 and may be used to perform compile 

time and/or runtime checks. One such check is that 
the magnitude of each <arith exp> must be no 
larger than the largest value of type <type spec> . 

RANGE information may also be used in an implemen- 
tation dependent manner to pack integers (cf. the 
DENSE attribute) . 

- For SCALARs, the <arith exp>s are converted to 
scalars^ and may be used tq perform compile time 
and/or runtime checks. 

- For FIXEDs, the <arith exp>s must be literals or 
FIXEDs and may be used to perform compile time 
and/or runtime checks . 

- Fop matrice and vectors, the RANGE is interpreted 
as an assertion about each component. 


1 See Appendix F. 

2 See Appendix D. 



I 


RESTRICTIONS ]FOR SIMPLE VARIABLES AND MAJOR STRUCTURES; 



1. The asterisk form of array specification can oiily be 
applied to an <identifier> if it is a formal parameter 
of a procedure or function. The actual length of the 
array is supplied by the corresponding argviment of an 
invocation of the procedure or function. 

2. An array specification is illegal if the <identifier> 
is defined by the <type speo to be a major structure. 

3. The ACCESS attribute may only be applied to <identifier> 
names declared in a <compool block> or <compool template> . 

The LOCK attribute may only be applied to <identifier> 
names declared in a <compool block>‘, <compool template> 
or <program block>, or to the assign parameters of 
procedure blocks. 

4. The LATCHED attribute only applies to event variables 
(see Section 4,7) . 

5. The REMOTE and AUTOMATIC attributes are illegal for any 
<identifier> of EVENT type. They are also illegal if 
<identifier> is the input parameter of a PROCEDURE or 
FUNCTION block. 

6. The attributes DENSE, ALIGNED, and RIGID are illegal 
for major structures. 

7. The <initialization> attribute may not be applied to 
formal parameters of procedures and functions. 

8. The RANGE attribute may be applied only to integer, scalar, j , 

fixed, vector (f) and matrix (f) variables. I 142 

RESTRICTIONS FOR STRUCTURE TERMINALS; 

1. The asterisk form of array specification is not allowed. 

2. The <identifier> may not be defined to be an unqualified 
structure by the <type speo. Otherwise, the type 
specification is the same as for simple variables. 

3. The appearance of any minor attributes except DENSE, 

ALIGNED, RIGID, and RANGE is illegal. Appearances of DENSE j ^42 
and ALIGNED override such appearances on the minor 
structure levels or on the <structure template> name 
itself. 

4. An array specification is illegal if the <identifier> 
is defined by the <type speo to be a major structure. 
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RESTRICTIONS FOR MINOR STRUCTURES: \ 

1. The <type spec> for a minor structure name must be 
empty (see Section 4.7). 

2. No array specification is allowed. 

3. No attributes except DENSE , ALIGNED and RIGID are allowed. 
J^pearances of DENSE and ALIGNED at any level of the structure 
override such appearances at higher levels or on the 
<structure template> name itself. The appearance of 

RIGID causes structure terminals within the minor 
structure to be organized in the order in which they 
are declared. However, RIGID at the minor structure 
level will not affect the order of data within an 
included template specified by a structure template 
<type spec>. 


EXAMPLE: 

STRUCTURE Y: 

1 A SCALAR/ 

1 B VECTOR (4)/ 

1 D MATRIX(4/4) J 

STRUCTURE Z RIGID; 

If bit(13)/ 

1 G Y-STRUCTURE> 

1 H CHARACTER (10); 

The order within Z will be: but the order 

within G will not necessarily be as declared by Y. 



4.6 Label Deciarative Attributes. 


A label declarative attribute defines an <identifier> 
to be a <label> of some specific type, 

SYNTAX: 


WmI dadarativ* attributts 


PROCEDURE 


NONHAL MD-C numbtr 


typi sptc X7 


axampla; 

FUNCTION VECTOR (4) NONHAL Uh 


SEMANTIC RULES: 


The form FUNCTION <type spec> is used to define the name 
and type of a <function block> . Such a definition is 
only required if the function is referenced in the source 
before the occurrence of its block definition. 

Functions requiring definition this way are subjec-t to the 
following restrictions: 

• they must have at least one formal parameter? 

• none of their formal parameters may be arrayed. 

The type specification of the function declared is given by 
<type spec> (see Section 4.7). A function may be of any 
type except EVENT. 

The NONHAL (<number>) indicates that an external routine 
written in some other language is being declared. NONHAL 
(<number>) may be a factored attribute applied to a list 
of label declarations . The <number> is an implementation 
dependent indication of the type of NONHAL linkage. 

The form TASK is used to define the name of a <task ,o'ock>. 
It may be required if a <task block> is referenced before 
the occurrence of its definition. 
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4.7 Type Specification. 

The type specification or <type speo provides a 
means of defining the type (and precision where applicable) 
of data names and parts of structure templates. 


SYNTAX: 


TYPE ^ 
SPECIFICATION 


GENERAL SEMANTIC RULES : 

1. If <type speO is empty (i.e. there is no specification 
present) then the interpretation is as follows: 

• If the <type speo is that of a simple variable , function 
or structure terminal, then the implied type is 
SCALAR with SINGLE precision. 
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• The <type speo is otherwise that of a minor 
structure of a strucute template. 


2. If the <type speo is empty except for the keyword SINGLE 
or DOUBLE, the implied type is SCALAR with the indicated 
precision. 


3. The precision keywords only apply to VECTOR, VECTORF, 

MATRIX, MATRIXF, SCALAR, FIXED, and INTEGER < type speos. 
In the last case SINGLE implies a halfword integer,^ and 
DOUBLE a fullword integer. In the absence of a precision 
keyword, SINGLE is presumed. 



4. Any <arith exp> in a <type speo is. an unarrayed Integer 
or scalar expression computable at compile time (see 
Appendix F) . Its value is rounded to the nearest integer . 
(Specifying a scalar expression is exactly the same as 
specifying its integer equivalent.) 

5. The <scaling> attribute defines the scale factor (see 
Section 2.3.3) of the <type speo. The scale factor must 
be compile time computable (see Appendix F) . 


RULES FOR INTEGER, SCALAR, AND FIXED TYPES; 

1. Integer, scalar, and fixed types are indicated by the key- 
words INTEGER, SCALAR, and FIXED respectively. Note that 
scalar type can be indicated implicitly as described in 
General Semantic Rules 1 and 2 J 

RULES FOR VECTOR, VECTORF, MATRIX, AND MATRIXF TYPES; 


1. The keywords MATRIX and MATRIXF are used to indicate matrices 
containing scalar and fixed components respectively. If 
present, the two <arith exp>s in parentheses give the row 
and column dimensions of the matrix respectively. In the 
absence of such a size specification, MATRIX (3, 3) is implied, 

2. The keywords VECTOR and VECTORF are use.d-to iudicate vectors 
containing scalar and fixed components respectively. If 
present, the parenthesized <arith exp> indicates the length 
of the vector. In the absence of a length specification, 
VECTOR (3) is implied. 

3. The row and column dimensions of a matrix, and the length 

of a vector may range betwen 2 and an implementation dependent 
maxlmiam. 

4. In the remainder of this specification, the word vector is 
used generically for VECTOR and VECTORF where no confusion 
could arise. The word matrix is used generically for MATRIX 
and MATRIXF when no confusion could arise. 
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RULES FOR CHaSACTER TTCPES; 

1. Character type is indicated by the keyword CHARACTER. 

A character varieible is of varying length; the 
parenthesized <arith exp> following the keyword 
CHARACTER denotes the maximum length that the 
character variable may take on. A length must be 
specified. 

2 . The working length of a character data type may range from 
zero (the "null" string) to the defined maximum length. 

3 . The defined maximum length has an upper limit which is 
implementation dependent. 

4. The asterisk form of character maximum length specification 
must be applied to an <identifier> if it is a formal para- 
meter of .a procedure or function. The actual length infor- 
mation ot- the character string is supplied by the corres- 
ponding argument in the invocation of the procedure or 
function. 

RULES FOR BIT, BOOLEAN, AND EVENT TYPES ; 

1. The keyword BIT indicates type. The following parenthe- 
sized <arith exp> gives the length in bits. Its value 
may range between 1 and an implementation dependent upper 
limit. 

2. The keyword BOOLEAN indicates a bit type of 1-bit length. 

3. The keyword EVENT indicates an event type, similar to 
BOOLEAN, but which differs in that it has real time 
programming implications (see Section 8) . An <identifier> 
of event type is the only type to which the attribute 
LATCHED is applicable. The implications of the LATCHED 
attribute are discussed in Section 8.8. An <identifier> 
of event type may not be used as an input formal para- 
meter, nor may it be a structure terminal. 


RULES FOR STRUCTURE TYPE: 

1, The condition for the <type spec> indicating a minor 
structure are described in General Semantic Rule 1. 

2. The phrase <template name> -STRUCTURE defines an <identifier> 
to be a major structure whose tree organization is 
described by a previously defined template called 
<template name>. 
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3. The parenthesized expression or asterisk optionally 
following the keyword STRUCTURE specifies the structure 
to have multiple copies. The value specifies the number 
of copies, which may range from 2 to an implementation 
dependent maximum. 

4. The copy specification may only be an asterisk if the 
structure is a formal parameter of a procedure or function. 

The actual number of copies is supplied by the corresponding | 
argument of an invocation of the procedure or function I 15 

and must be greater than 1. " 

5. If the <identifier> name defined is the same as the 
< template name> of the template of the structure, 

then the structure is said to be unqualified . Otherwise 
the structure is said to be qualified . Templates used for 
non-qualified declarations may not contain nested 
structure references. * Section 5.2 contains material on 
some further implications of structure qualification. 

6. If the <type spec> of a function is STRUCTURE then no 
specification of multiple copies is allowed - 

7. If the <type spec> of a structure terminal is STRUCTURE, 
then no specification of multiple copies is allowed. 


Declarations of non-qualified STRUCTURES must occur in the same name scope 
as the template definition. 


4.8 Initialization. 


The <initializatlon> attribute specifies the initial 
values to be applied to an <identifier> . The circumstances 
under which the attribute is legal have been described in 
Section 4.5. 


SYNTAX: 



initiaiiution spedfication 


^nitialization^ 





/ mitfal ) 
\ '*« / 



example: 


§ ; see below 


INmAt(2#(1,3#5l) 


GENERAL SEMANTIC RULES; 


The <initialization> starts with the keyword INITIAL 
or CONSTANT. If it starts with CONSTANT, the value of 
the <.identifier> initialized may never be changed . It 
is illegal for <identif ier>s with CONSTANT <initialization> 
to appear in an assignment context. 
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2. The simplest form of an <initial list> is a sequence 

of one or more <expression>s computable at compile time. 
(See Appendix F) . 

3. A simple <initial list> of the form given in Rule 2. may 
be enclosed in parentheses, and preceded by <arith exp>#, 
where <arith exp> is any unarrayed integer or scalar 
expression computable at compile time. The value, rounded 
to the nearest integer, is a repetition factor for the 
initial values contained within the parentheses. This 
repeated <initial list> may itself become a component 

of an <initial list>, and so on to some arbitrary nesting 
depth. 

4. In addition to preceding a parenthesized <initial list>, 
<arith exp># may also precede certain unparenthesized 
items denoted collectively in the syntax diagram by § . 
These items are: 

• a single literal; 

• a single unsubscripted varicible name; 

• blank (i.e.^ the component (s) of the <identifier> 
should not be initialized) . 


5. The presence of an asterisk at the end of the <initial list> 
implies the partial initialization of an <identifier> . 


6. The order of initialization is the "natural sequence" 
specified in Section 5.5. 


RULES FOR INTEGER, SCALAR, AND FIXED TYPES: 

1. If the <identifier> has no array specification, the 
<initial list> must contain exactly one value. 

2. If the <identifier> has an array specification, then one 
of the following must hold: 


14 7 


• the number of values in the ^initial list> is 
exactly one, in which case all elements of the 
array are initialized to that value; 

• the number of values in the <initial list> is 
exactly equal to the number of array elements to 
be initialized; 


• the <initial list> ends with an asterisk, in which 
case the number of values must be less than the 


{ 
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number of array elements to be initialized, and 

partial initialization is indicated. 

3. <expression> must be an unarrayed INTEGER*, SCALAR , or FIXED 
expression computable at compile time (see Appendix P) . Type 
conversion between INTEGER and SCALAR is allowed where 
necessary. 

4. If the <identifier> is of type FIXED, <expression> must be a 
literal or of type FIXED. If the scaling of the expression 
and the <identifier> are both defined, they must be equal. 

RULES FOR VECTOR, VECTORF, MATRIX, AND MATRIXF TYPES; 

1. If the <identifier> has no array specification, then one 
of the following must hold; 

• the nxiraber of values in the <initial list> is 
exactly one, in which case all components of the 
VECTOR or MATRIX are initialized to that value; 

• the number of values in the < initial list> is 
exactly equal to the number of components to be 
initialized; 

• the <initial list> ends with an asterisk, in which 
case the number of Values must be less than the 
niomber of components to be initialized, and partial 
initialization is indicated. 

2. If the <identifier> has an array specification, then 
one of the following must hold; 

• the number of values in the < initial list> is 
exactly one, in V7hich case all the components of all 
the array elements of the VECTOR or MATRIX are 
initialized to that value; 

• the number of values in the <initial list> is 
exactly equal to the number of components of the 
VECTOR or MATRIX , in which case every array 
element takes on the same set of values; 

^ the number of values in the <initial list> is 
equal to the total number of components in all 
array elements; 
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• the < initial list> ends with an asterisk; in 
which case the number of values must be less 
than the total nvunber of components in all array 
elements, and partial initialization is indicated. 

3. <expression> must be an unarrayed integer, scalar, or fixed 
expression computable at compile time. Type conversion be- 
tween integer and scalar is allowed where necessary. 

4. If the identifier is of type MATRIXF or VECTORF, expression 
must be a literal or be of type FIXED. If the scaling of 
the components and the scaling of the <expression> are both 
defined, they must be equal. 

RULES FOR BIT, BOOLEAN, EVENT AND CHARACTER TYPES; 

1. If the <identifier> has no array specification, the 
< initial list> must contain exactly one value. 

2. If the <identifier> has an array specification, then one 
of the following must hold: 

• the number of values in the <initial list> is 
exactly one, in which case all elements of the 
array are initialized to that value; 

• the number of values in the < initial list> is 
exactly equal to the number of array elements to 
be initialized; 

• the <initial list> ends with an asterisk, in which 
case the number of values must be less than the 
ntimber of array elements to be initialized, and 
partial initialization is indicated, 

3. If an <identifier> of Bit, Boolean, or Event type is 
being initialized, <expression> must be an unarrayed 
<bit exp> computable at compile time (see Appendix F.). 

If an Event <identifier> has the LATCHED attribute, then 
it may be initialized to the value TRUE or FALSE (or 
their equivalent) . If it does not have the LATCHED 
attribute, it can not be initialized, (see Section 8.8). 

In the absence of <initialization> all events are implicitly 
initialized to FALSE. 

4. If an <identifier> of CHARACTER type is being initialized, 
<expression> must be an unarrayed <char exp> computable 
at compile time (See Appendix F,), 


RULES FOR STRUCTURE TYPES: 


1. Only a major structure <identifier> may be initialized. 

2. If the < identifier > has only one copy, then one of the 
following must hold: 

• the number of values in the <initial list> is equal 
to the total number of data elements in the whole 
structure; 

• the <initial list> ends with an asterisk, in which 
case the number of values must be less than the number 
of data elements in the whole structure, and partial 
initialization is indicated. 

3. If the <identifier> has multiple copies, then one of the 
following must hold: 

• the total number of values in the < initial list> is 
exactly equal to the total number of data elements 
in one copy of the structure, in which case each copy 
is identically initialized; 

• the number of values in the <initial list> is equal 
to the total number of data elements in all copies 
of the structure; 

• the <initial list> ends with an asterisk, in which 
case the number of values must be less than the total 
number of data elements in all the copies of the 
structure, and partial initialization is indicated. 

The type of each <expression>. must be legal for the type 
of corresponding structure terminal initialized (see the 
Semantic Rules for initialisation of simple variables 
of each type) . 


3 . 


5 . 


DATA REFERENCING CONSIDERATIONS 


Central to the HAL/S language is the ability to 
access and change the values of variables. Section 4 dealt 
comprehensively with the way in which data names are defined. 
This section addresses itself to the various ways these names 
can be compounded and modified when they are referenced. 





In Section 4.5 the term "simple variable" was intro- 
duced to describe a data name which was not a structure, or 
part of one. When a simple varicdale is defined in a <declare 
group>, it is syntactically denoted by the <identifier> 
primitive. Thereafter, since its attributes are known, it 
is denoted syntactically by the <§var name> primitive, where 
§ stands for any of the types arithmetic, bit, character, 
or event. 



5.2 Referencing Structures, 


When an <identifier> is declared to be a structure, 
its tree organization is that of thfe template whose <template 
name>. appears in the structure declaration (see Section 4.7). 
References to the structure as a whole (the "major structure") , 
are obviously made by using the declared <identifier> , which 
syntactically becomes a < structure var names ^ The way in 
which parts of the structure (its minor structures and 
terminals) are referenced depends on whether the structure 
is "qualified" or "unqualified" (see Section 4.7). 

• If a structure is "unqualified", then any part of 
it, either minor structure or structure terminal, 
may be referenced by using the name of the part as it 
appears in the <structure templates. If a minor 
structure is referenced, the name becomes syntact- 
ically a <structure var names, if a structure 
terminal is referenced, then syntactically the name 
becomes a <§var names, where § stands for any of the 
types arithmetic, bit, character, or event, as 
specified in its <attributess in the template. 

• If a structure is "qualified", then any part of it, 
either minor structure or structure terminal, is 
referenced as follows. First the major structure 
name is taken. Then starting at the template name, 
the branches of the template are traversed down to 
the minor structure or structure terminal to be 
referenced. On passing through every intervening 
minor structure, the name is compounded by right 
catenating a period followed by the name of the minor 
structure passed through. The process ends with the 
catenation of the name of the minor structure or 
structure terminal to be referenced. If a minor 
structure is being referenced, the resulting "quali- 
fied" name becomes syntactically a <structure var 
name>. If a structure terminal is referenced, then 
syntactically it becomes a <§var name> , where § 
stands for any of the types arithmetic, bit, character, 
or event, as specified in its <attributes> in the 
template. 


OE POOR 


PAGE 

(QUALITY 


example: 


STRUCTURE A: 

1 B. 

2 C, 

3 E VECT0RI3), 
3 F SCALAR, 

2 6 . 

3 H EVENT, 

3 I INTEGER. 

1 J BIT(16); 




Structure template 


DECLARE A A-STRUCTURE, 
Z A-STRUCIURE; 


If 



unqualified'* 


"qualified" 


i) references to parts of structure A - 

G I J 

ii) references to corresponding parts of structure Z - 

Z.B.G Z.B.G.I Z.J 




5. 3 Subscripting. 


For toe remainder of this section, a data name with 
known <attributes> is denoted syntactically by <§var name>, 
where § stands for any of the types arithmetic, bit, charac 
ter, event, or structure. It is convenient to introduce 
the syntactical term <§var> to denote any subscripted or 
unsubscripted <§var name> . 


SYNTAX! 


arith 

bit 

char 

structure 

event 


variables 


6 var name 


example: 


S>— I subscript 


AttO 10 


It IS also useful to introduce the syntactical term 
<variable> as a collective definition meaning any type of 
<§var>. 


SYNTAX: 


variable 


arith var 


bit pseudo-var 


structure var 















SEMANTIC RULES: 

1. <bit pseudo-var> is a reference to the SUBBIT pseudo- 
variable. An explanation of its inclusion as a 
<variable> is given in Section 6.5.4. 
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5.3.1 CZoAiiA 0(5 Su6A<yup^ng. 


In HAL/S, there are three classes of subscripting 
which may be potentially applied to <§var name>s : structure, 
array, and component subscripting. 

• Structure subscripting can be applied to 
arithmetic, bit, character, and event variables 
which are terminals of a stiructure which has 
multiple copies. It can also be applied to the 
major and minor structure varicd^le names of such 
a structure. Structure subscripting is denoted 
syntactically by <structure sub>. 

• Array subscripting can be applied to any arith- 
metic, bit, character, and event variables which 
are given an array specification in their declara- 
tion. This includes both simple variables and 
structure terminals. Array subscripting is 
denoted syntactically by <array sub>. 

• Component subscripting can be applied to simple 
variables and structure terminals which have one 
or more component dimensions (i.e. which are made 
up of distinct components) . The applicable types 
are vector, matrix, bit and character. Component 
subscripting is denoted syntactically by <component 
sub> . 

The three classes of subscript are combined according to a 
well-defined set of rules. 
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SYNTAX 


uibtcript construct 


subscript 


componont 

sub 


array sub 


component 

sub 


j structuro sob \ 


component 

sub 


example: 


l;J,K : L 



component 

sub 


SEMANTIC RULES: 

1. The syntax diagram shows 10 different ways of 

combining the three classes of subscripting. The 
following table shows when each of these combinations 
is legal for simple variables and structure terminals 
In the table, the following abbreviations are used: 

<component sub> ->■ C 

<array sub> -> A 

<structure sub> -*■ S 










Interpretation of<§ var name> 


unarrayed arrayed unarrayed 

simple simple struc tnre 

variable variable terminal (p 



© It is assumed that the structure has multiple copies . 
If not^ corresponding columns for simple variables 
apply. 


In the case of a <structure var name> relating to a 
major structure with multiple copies, or to a r.inor 
structure of such a major structure, the following 
forms are legal : 

S 


No subscript is possible if the major structure has no 
multiple copies . 


ORIGINAL PAGE IS 
OF POOR QUALiTY 




















examples: 


X: 


< array sub> 




P is any arrayed simple variable 



equivalent only if P is of 
integer, scalar, or event type 


ii) 


1 


<coinponent sub> 



Q is cuiy simple variable of integer, 
scalar, or event type 


<array sub> (see example i) 


<structure sub> 



Q is any unarrayed structure ter- 
minal* of integer, scalar, or evcvit 
type 


ill) 

t n <structure sub> H R is any structure terminal* 

equivalent forms - 


R 


X 


equivalent only if R is of unarrayed 
integer, scalar, or event type 



<component sub> 
<array sub> 
<structure sub> 



S is an arrayed structure terminal^ 
of vector, matrix, bit, or 
character type 


* of a structure with multiple copies 




GENERAL SEMANTIC RULES : 

1. A <structure sub>, <array sub>, or <component sub> 
consists of a series of "subscript • expressions " 
separated by commas. Each subscript expression 
corresponds to a structure, array, or component 
dimension of the <§var name> subscripted. 
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149 


2 . There are four foms of subscript expression: 

• the simple index; 

• the AT-partition; 

• the TO-partition; 

• the asterisk. 

3. The simple index form is denoted in the diagram by a 
single sub exp . Its value specifies the index of a 
single component, array element, or structure copy 

to be selected from a dimension. 

4. The AT-partition is denoted by the form <arith exp> AT 
<sub exp> . The value of <arith exp> is the width of the 
partition, and that of <sub exp> the starting index. 

5. The TO-partition is denoted by the form <sub exp> TO 
<sub exp>. The two <sub exp> values are the first and 
last indices^ respectively^ of the partition. 

5. The asterisk form, denoted in the diagram by *, specifies 
the selection of all components , elements , or copies 
from a dimension. 

7. <sub exp> may take any of the forms shown. The value of 
# is taken to be the maximvun index-value in the revelant 
dimension. (For character variables, this is the current 
length) . 

B. Any <arith exp> in a subscript expression is an unarrayed 
integer or scalar expression. Values are rounded to the 
nearest integer. 
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5,3.3 StmdtuAd Sabi c/UptLng , 


Major structures with multiple copies, or the minor 
structures or structure terminals of such structures may 
possess a <structure sub> . Since there is only one dimension 
of multiple copies, the <structure sub> may only possess one 
subscript expression. The effect of such subscripting is to 
eliminate multiple copies, or at least to reduce their number. 

RESTRICTIONS ! 

1. Errors result if any index value implied by a subscript 
expression lies outside the range 1 through A/, where hi 

is the number of copies specified for the major structure. 

2. If the subscript expression is a TO- or AT-purtition, 
the width of the partition must be computable at compile 
time. This is .^juaranteed by enforcing the following 
restrictions . 

• in the form <arith exp> AT <sub exp>, the value of 
<arith exp> must be computable at compile time 
(see Appendix F.). 


• in the form <sub exp> TO <sub exp>, the values of 
both <sub exp>s must be computable at compile time. 


examples: 


STRUCTURE A: 

1 B SCALAR, 

1 C INTEGER, 

1 D VECT0R(6); 

• 


DECLARE A A-STRUCTDRE(20); 

^20 

20^ copy of A 

^2 AT 10 ; 

10^^ and 11^^ copies of A 

(semicolon optional) 


C from 1®^ copy of A 

‘^4 TO 6; 

D from 4'^^ through fith copies of A 

(semicolon enforced) 

Note; 

components 4 through 6 of D from 

all copies of A 
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5.3.4 AfUuxy SubiCA^pting. 

Any simple variable or structure terminal with an 
array specification (see Section 4*5) may possess an <array 
sub>. The number of subscript expressions in the <array sub> 
must equal the number of dimensions given in the array speci- 
fication. The leftmost subscript expression corresponds to 
the leftmost dimension of the array specification, the next 
expression to the next dimension, and so on. 


RESTRICTIONS : 


1. Errors result if any index value implied by a subscript 
expression lies outside the range 1 through N, where N 
is the size of the corresponding dimension in the array 
specification. 


2. If the subscript expression is a TO- or AT- partition, 
the width of the partition must be computable at compile 
time. This is guaranteed by enforcing the following 
restrictions ; 

• in the form <arith exp> AT <sub exp>, the value of 
<arith exp> must be computable at compile time ; 

• in the form <sub exp> TO <sub exp> , the value of 
of both <sub exp>s must be computable at compile 
time. 


examples: 

STRUCTURE P: 

1 Q ARRAY(5) SCALAR. 
1 R SCALAR; 


DECLARE P P-STRUCTURE(IO); 
DECLARE S ARRAY(5) SCALAR, 

T ARRAY(5) VECT0R{6); 


Note;T, 



5^^ array element of Q in all copies of J 

^1;2 TO 3; 

2^^ and 3^^ array elements of Q in 1®"*^ 
copy of P ( colon optional) 

^4 TO 5: 

til 

4^^ through 5 ^ array elements of S 

( colon optional) 

^2 AT 2: 

2^^ and 3^^ array elements of T 

( colon enforced) 

2 mT 2 

components 2 and 3 in all array elements 
of T 
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5. 3. 5 Component Sub-ic/Upting . 


Simple variables and structure terminals o£ vector, 
matrix, bit and character type may possess component sub- 
scripting because they are made up of multiple distinct 
components . 

• Those of bit, character, and vector types must 
possess a <component sub> consisting of one 
subscript expression only; 

• Those of matrix type must possess a <component 
sub> consisting of two subscript expressions. 

In left to right order these represent row and 
column subscripting respectively. 


RESTRICTIONS: 

1. Errors result if any index value implied by a subscript 
expression lies outside the range 1 through N, where N 
is the size of the corresponding dimension in the type 
specification. 

2. For bit, vector and matrix types, if the subscript 
expression is a TO- or AT-partition, the width of the 
partition must be computable at compile time. This is 
guaranteed by enforcing the following restrictions: 

• in the form <arith exp> AT <sub exp> , the value 
of <arith exp> must be computaiole at compile 
time; 

• ill the form, <sub exp> TO <sub exp> , the values 
of both <sub exp>s must be computable at compile 
time. 

3. The subscript expressions of a character type need not 
be computable at compile time. 


SPECIAL RULES FOR VECTOR, VECTORF, MATRIX, AND MATRIXF TYPES: jl47 

The <component sub> of a variable of vector or matrix type 
can Sometimes have the effect of changing its type. The 
follov/ing rules apply: 
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o 


If a VECTOR or VECTORP type is subscripted with a simple 
index < component sub^ then since bne^ component is^ being 
selected, th^ resulting <arith var> is of SCALAR Sr FIXED 
type respectively.. 


If Only one of the two subscript^pres^Lons in a <component sub> 
of a MATRIX or MATRIXP type is |isimple indea ^ th en one row or 
column is beings selected, and the result issf^erbfore an 
<erith var> of VECTOR or VECTORF type respectively. ’ If both 
subscript '’expressions are of simple index foirm, then one com- 
ponent “of the MATRIX or MATRIXF is being selected, and the 
result, is an <arith°var> of SCALAPi or FIXED type respectively. 

The <scaling> attribute defines the scale- factor (see - 

Section 2.3.3) of the <type speo. The scale factor must 
be compile time computable (see Appendix F) . 


examples: 


DECLARE M MATRIXO, 3), 

: (: ARRAY(2) CHARACTERiS); 


'1:2 TO 7 


characters 2 through 7 of 
array elemefit of C 

column I of matrix M (vector) 


3rd stjomppnent of 3*^^ row 
of M (scalar) 




5. 4 The Property of Arrayness. 


A <^yar name^ which is a simple variable is said to 
be "arrayed**, or to possess arrayness " , i£ any array specif 
fication appears in it^^ declaration. The number of dimensions 
of arraynessl is the number of dimensions given in the array 
specification. 


A <Svar name> which is a structure terminal rs said to 
be arrayed oiyto possess arrayness if either or both of the 
following hold: 

• an array specification appears in its“ declaration 

, ip a structure template; 

• the structure of which <§var name> is aterminalo 
has multiple copies . 

The number of dimensions of arrayness is the sum of the 
dimensions originating from each source. 

„ Appending structure or array subscripting to a » 

ikivar name> may reduce the number and size of array dimensions 
of the resulting <fvar>. 


The arrayness of HAL/S expressions originates ultimately 
Q from the <§var>s contained in them. It is a general rule 

that all arrayed <§var>s in an expression must possess identical 
arrayness (i.e. the number of dimensions of arrayness, and 
their corresponding sizes must be the same) . Although the 
forms of subscript distinguish between array dimensions, and 
' structure copy dimensions, no distinction between f hem is 
mads as far as thh matching of arrayness is concerned. 





Q 


5. 5 The Nitu ral Sequence of Data Elements. 


There" are several kinds of opei^tion in the HAL/S 
language which require oper^ds with multiple components, 
array elemerits , and structure copies to be unraveled into 
a linear string of data elements. The reverse proc€^$s of 
"reraveling** a linear string of data elements into components, 
array elements , and structure copies also occurs. Two major 
occurrences of these processes are in I/O (see Section 10) , 
and in conversion functions (see Section 6.5). 

The standard order in which this unraveling and 
reraveling takes place is called the "natural sequence”. 

By applying the following rules in the order they are stated, 
the natural sequence of unraveling is obtained. By applying 
the rules in reverse or^|tr, and replacing "unraveled" by 
"reraveled" , the natura£>^equence for reraveling is obtained. 

tfe) 

RULES FOR MAJOR AND MINO’R STRUCTURE: 

1. If the operand is a major stinicture with multiple copies, 

each copy is unraveled in turn, in orders of increasing 
index. If the operand is a minor structure of a multiple- 
copy structure, then the copy of the minor structure in 
each structure copy is unraveled in turn in order of 
increasing index. . 

2. The method of unraveling a copy is as follows. Each 
structure terminal on a "branch" connecting back to the 
given major or minor structure operand is unraveled in 
turn. The order taken is the order of appearance of the 
terminals in the structure template. 

3. Each structure terminal is unraveled according to the 


Rules aiven below. 





RULES FOR OTHER OPERANDS: 

1. An operand of any type (integer, scalar, fixed, vector, . 

matrix, bit, character, or event) may possess arrayness as |147 
described in Section 5.4. Each dimen^io|p c>f arrayness, 
starting from the leftmost is unraveled in turn , in ordef 

of increasing index. 

2. Integer, scalar , ^ixed|l bit, character, and event types j 147 

are considered for% unraveling purposes as having only one 
d#^^a element. 

3. Vector types l^re unraveled component by component, in 
order of increasing index. 

4. Matrix types are unraveled row by row, in order of 
increasing'^ index. The components of each row are 
unraveled in turn in order of increasing index. 


example: 




DECLARE V ARRAYI2.2) VECT0RI3) : 




• order of unraveling of V Is V. , , 

• • • 

. i-1.2 


/ 

• order of unraveling of each V. Is 

• I • 

''i.j:* ' 

j-1.2 

• order of unraveling of each V. . . is 

• e J* 


k“l,2.3 


(standard HAL/S subscript notation 

. ' 0 

used) 
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6. DATA MAN! PUUTIONAND.EXPRESS IONS 

0 „ 


€ 


An express ion, an algorithm used for computing a 
vj^lue. In HAL/S expressions are formed by combining together 
b|>er;atbrs with .operands in a well-defined manner . Operands 
generally are variables/ literals, other expressions, and 
factions The type of an expression is the type of its 
result, which is not necessarily the same as the types of 
its operands.; 

O . 0, 

InoHAL/S, expressions ere divided into three major 
classes according to their usage. " 


" • regular expressions -appear in a very large number 
of contexts through the language; e.g.^ 
in assignment statements , as arguments to proce- 
g dures and functions , and in I/O statements . 

Typical regular expressions are arithmetic, bit, 
and character expressions. They are collectively 
denoted by <expressiGn>. o 

, 0- i? 

■ ..O'- 

• eonditional expressions are used to express 
combinations of relatibhships between quantities , 
and are found in IF statements, and in WHILE and 
UNTIL phrases. They are denoted by <conditlon>. 

• event expressions are used exclusively in real time 
programming statements. 

■ i 


0 


fi 




€-1 


I 






6.1 Regular Expressions 


Regular expressions comprise eurithmetic Expressions , 
bit expressions and character expressions, together with a 
limited form Of structure expression. As a generic form, 
<expression> appears in the assignment statement, as the input 
arguments of procedure and function blocks, and in the WRITE 
statement . 


SYNTAX; 


•Mprwiion 


•xpriKsion 


arith exp 


char exp 


structure exp 


Descriptions of < arith exp>v <bit exp>, <char exp>, and 
<structure exp> are given in the^^following subsections. 


ORIGINAL PAGE 
^ OF POOR QUALITY 











b. 1 , 1 AfUthm&tcc Exp^e&44.ons 


Arithmetic expressions include integer, scalar, fixed, 
vector, and matrix expressions. Collectively they are known 
by the syntactical term <arith exp>. 


SYNTAX: 


<f ithm«tic,txprtuk>n 




SEMANTIC RULES: 

1. An <arith exp> is a sequence of <arith operand>s« 

separated by infix aritlimetic operators, and possibly 
preceded by a unai^y plus or minus . 


2. The form < > is used to show that thfe two <a^th , ^ 
operand>s are separated by one or mo‘:e spaces. 

It signifies a product „ between the <4rith 'operand>s. 





. The’ syntax diagrafi^ f or <arith exp> produces a sequence 
extensible on the right. Any ^sequence produced is not 
necessarily to be considered as evaluated from left to 
right. The order of evaluation of each operation 
3 ' in the sequence is dictated by operator precedence. 

‘ ' O 

► Not all types of <arith operand> are legal in &VBxy infix 
operation. The following table stunmarizes all possible 
forms, by indicating the result of each legal operation. 



Notes: o 

o n '■ .. 

In ope^iitions with vector and itiatrix operands, the sizes of the operands 
must compatible with the operation involved, in the usual mathematical 
sense. ' 

outer product . 

ii'- 
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0 


^ cross product - valid for 3-vftctor^ortly. 
dot product. . ff 


0 

/ 


element of the vector or matrix i4 multiplied ly the integer^ I 147 


scalv^r, or fixed. 


^ ^>|very element of the vector or matrix |.s divided by the integer 




scalaur. 


if the right operand is literally "T"' the transpose is indicated. 

If the right operands is literally "O" the result is an identity 
matrix. If the right operand is a positive integer number, a 
c repeated product is implied. If the right operand is a negative 
integer number, repeated product of the inverse is implied. Ihese 
are the only legal foms. 

,0 

© the operands are converted to scalar before division* 

the operation is undefined if the value of the left operand is 
negative^ and the value of the right operand is non integral. 

jj(^ the result is a scalctr except if the right operand is a non- 

negative integral compile time constant in which case the result 
is integer. 

the right operand must be a positive integral compile time constant. 




147 


5. Except .as noted in Rule 4 (+) , if one operand in ah operation 
is of INTEGER type and the other operand is of SCALAR, VECTOR, 
or MATRIX type, the INTEGER is converted to a SCALAR before 
performing the operation. 

u' 

6. If one operand in an operation is INTEGER and the other 
operand is FIXED, VECTORF, or MATRIXF, the type of neither 
operand is converted before performing the operation . 

7. If the two operands of an operation are of differing precision, 
the result is double precision; otherwise the precision of the 
result is the same as the precision of tK2i>operands . This is 
true in all cases except where one operand only is of integer . 
type. In this case the precision of the result is the same as' 
the precision of the non-integer operand. 

A ' , 

8. For the purpose of deteraining the scaling of an expression 

involving an INTEGER and a FIXED , VECTORF , or MATRIXF, <^an 
INTEGER' is defined to have a scaling of 2®. ’ 

When performing additions or subtractions with operands of 
FIXED, VECTORF, or MATRIXF type, if the scaling of both 
operands is defined then tlPe scalings must be equal and the 
scaling o:|, the. result is der\ined to be the same as the scaling 
of the o^lerand^. ..e . \ 
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9. 


0. When performxng multiplication or division with at least one 
operand of type FIXEC^ VECTORF, or MATRIXF, if the scaliiig / 
pf both operands is defined then the scaling of the result is 
jdefined to be the product or quotient of the scaling of the” 
{Operands. 

i . ' o • ^ ' 

1. jwhen performing exponentiation of a FIXED or MATRIXF, 

iif the scaling of the operands is defined then the scaling e, 
jof the result is defined to be, the^ scale factor of the left 
joperand taken to the power of the right operand. 

2. If either or both of the operands of an operation have 
RANGE attributes, the semantics of the operation are 
unchanged, but a compiler may detect and report range 
incompatibilities. 

\ 

PRECEDENCE RULES: ° 1 

1. The following table sunmiarizes the precedence%ules 
for arithmetic operated: \ “ 


Operator 

Precedence 

Operation 

** <i- 

FIRST 

1 

Q ■ 

exponentiation'^ 

<> 

2 

multiplication 


3 

cross-product 

.m 

4 

dot-product 

/ ^ 

5 

^ division 


6 

addition and unary plus 

: 1 

6 

LAST 

subtraction and unary 
minus 


2.(i If two cperations with the same precedence follow each 
other, then the following rules apply: 

operators **, / are evaluated right-to-left; 
all other operators are evaluated left-to-right; 









0 


3. Overt id ing Rules 1 and 2 , the operators <>, *, and . 
are evaluated so as to minimize the total number of 
elemental multiplications required. However, ’this rule 
does not modify the/feffectiive precedence order in cases 
where it would cause the insult to be numerically 
different, or the ope^jijyjjun to biijrytiegal . 

An <arith operand> appearing in an ,«?erith ^xp> has the 
following form; 


SYNTAX: 


<3 



1. An <arith operand> may be an arithmetic variable, an 
arithmetic expression^, enclosed in parentheses, a 
< normal function> of the appropriate type (see Section 
6.4), an <arith conversion> function ('see Section 6.5.i), 
or a literal <number>. 


2. The precision of an <arith operand> may be converted 
by subscripting it with a <precision> specifier (see 
Section 6.6). If the operand is an <3arith var>»this is 
£rue only if it has no < subscript> . ^ 

3. Only integer, scalar, and fixed <arith operand>s may 
have the form <number> , 


4. The scaling of an <arith operand> may be converted by 
subscripting, it with a <scaling> specifier (see Section 
6,7). If the operand is an <arith var> this is true only 
if it has no <subscript>,l Scaling operators are defined 
for arith operands which are numbers or are of type 
FIXED, VECTORF , or MATRIXF. 

^Since a subscripted < arith vaf> is an example pf an 
<arith exp>, the <precision> or <scaling> specifier may be 
applied by first enclosing the <arith exp> in parentheses. 
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6, 1. 2 Ret Exp^e6MOn4* 

„ ‘ 

A bit expression is known by the syntactical term 
<bit exp>. :iX7 


SYNTAX: 



SEMANTIC RULES : 

1. A <bit exp> is a sequence of <bit operand>s separated 
by bit operators. 

2. The syntax diagram for <bit exp> produces a sequence 
•j, extensible on the right. Any sequence produced is 

not necessarily to be considered as evaluated from left 
to right. The order of evaluation of each infix operation 
is dictated by operator precedence: 







bit operand 









'■" o 


Q 


SEMANTIC RULES : 

1. A <bit operand> may be a <bit var>, a <bit ixp> enclosed 
in parentheses, a <blt literal>, a <normal function> of 
bit type (see Section 6.4) , „a <bit conversion> function, 
or a <bit pseudo-var> (see Sections 6.5.3 and 6.5,4). 

2. In addition a <bit operand> may be an <event var> or 

a <process-event naroe> (see Section 8.9). Events and 
process**'events are treated as BOOLEAN (1-bit) <bit operand>s. 

3. Any form of <bit operand> may be prefaced with the NOT 

' ( -^ ) operator causing its logical complement to be evaluated 
prior to use within an expression. Note that associating 
the NOT operation with the <bit operand> syntax achieves 
an effect similar to placing the NOT operator in the bit 
'expression syntax at the highest lev&l of precedence. 
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6 . 1.3 ChOAOCttfL Expn.QA64.0M. 


A character expression is known by the syntactical 
term <char exp>. 


SYNTAX: 



SEMANTIC RiiJLES : ° 

/ 

1. A <char exp> is a sequence of operands separated by the 
catenation operator CAT ( | j ) . Each operand may be a 
<char operand> or an integer or scalar <arith exp>. 

2. The sequence of catenations is eval,uated from left to 
right. 

3. Integer and scalar <arith exp>s are converted to character 
strings according to the standard conversion rules given 
in Appendix D . 
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A < char operand> appearing a <char exp> has the following 
fonn. 


SYNTAX: 


chftraefBf oamnd 


( VJchK tup 


normal function 


char literal 


•xampM: 


char conversio 


SEMANTIC RULES : 


1. A <char operand> may be a character variable, a ' 
<char exp> enclosed in parentheses , a <char iiterai> , 
a < norma 1 function> of character type (see Section 6.4) 
^ or a <char conversion> function (see Section 6.5.3). 













6 . 1.4 


ptfiuctux& ExpfLU4lOM 


, Since there are no manipulative expressions for 
structures, a < structure exp> merely consists of one 
structure operand. 

SYNTAX : 



SEMANTIC RULES: 


1. A <structure exp> consists of ori© Structure operand which 
„may be either a'<structure var>, or a <normal function> of 
"structure type (see Section 6.4). 


6,1.5 AfOiaij pAop&fiM&6 o{ Exp^zi6-co Hi. ' 

Any regular expression may have an array property 
by virtue of possessing one or more arrayed oPG^^nds . The 
evaluation of an arrayed regular expression iihplies element- 
by-element evaluation of the expression. For any infix opera- 
tion with an array property the following must be true. 


SEMANTIC RULES: 

1* If one of the two operands of an infix operation are 
arfayed, then evaluation of the operation using the 
unarrayed operand and each element of the arrayed operand 

is implied. The resulting arr^ has the same dimensions 
as the arrayed operand. 

2, If both of the operands of an infix operation are arrayed, 
then both operands must have the same array dimensions . 
Evaluation of the operation for each of the corresponding 
elements of the operands is implied . Tha\resulting array 
has the same dimensions as the operands . ■ , 
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6.2 Conditional Expressions. 


Conditional expressions express combinations of relatioA 
ships between quantities. The HAL/S representation of cr^la- 
tion betweeh quantities is a <comparison>G <comparison>S are 
combined with logical operators to form conditional exE^xessions 
or <condition>s . » 


SYNTAX: 


oofiditional txpmiton 


cofiditiofi , 


conditional optrand 


axampM: 


|A>B) | (A >C) 


SEMANTIC RULES: ^ // 

1. A conditional expression or f^condition> is a sequence 

of <conditional operand>s separated by logical operators 

2. The syntax diagram for <condition> produces a sequence 
extensible on the right. Any sequence produced is not 
necessarily to be considered as evaluated from left to 
right. The order of evaluation of each infix operation 
is dictated by operator precedence: 







: 

OperatOj^ 

Precedence 


AMD, & 

FIRST 

1 

O', 

OR, 1 

2 



LAST 


If two operations with the same precedence follow each 
other, they are evaluated from left to right. 

c 

3. Tha operations ANp\(a) and OR (1) denote logical inter 
section and union respectively. 

i) 

A <conditional operand> appearing in a ,<condition> has the 
following form, ® 


SYNTAX; 



SEMANTIC RULES : 

1. A <conditional operand> is either a <comparison> or 
a parenthesized <condition> . The latter form may be 
preceded by the logical NOT C ) operator . 

2. A <coinparison> is a relationship between the values of 

two arithmetic, bit, character or structure operands . 
The result of a <comparison> is either TRUE or; PAL-S^ , 
but cannot be used as a boolean operand in a bit expres 
sion. ^ ^ ^ 
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6.2.1 A^Uthme^c Compa/u&onA, 


An eurithmetic <comparison> is a comparison between 
two arithmetic expressions. 


SYNTAX: 


oompartson 


arithtxp 


arith exp 


example: 


SEMANTIC RULES: 

' . o 

1. The types of < arith exp > operand must in general match, 

with the following exception : in a comparison with = 
mixed integer and scalar operands , the integer operand 
is converted to scalar . // 

2. If the precisions of the <arith exp> operands are mixed 
then the single precision operand is converted to double 
precision. 
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c 


Not all types of <arith exp> are legal for every type 
of arithmetic comparison. The unshaded boxes in the 
following table indicate all legal forms. </ 


operands 


Operator 


NOT> NOT< 

< ss > = 


VECTOR 

VECTORF 


MATRIX 

MATRIXF 

INTEGER 

SCALAR 

FIXED 



If the operands are vectors or matrices, the 
<comparison> is carried out on an e,lement-by-element 
basis. 

• If the <comparison> operator is =, the result is 
TRUE only if all the elemental comparisons are TRUE. 

• If ° the <comparison> operator is NOT= (“<=), the 
result is TRUE if any elemental comparison is 
TRUE. 


If one or both of the <arith e?xp>s are arrayed then" only 
the operators = and NOT- ir*-) aifk legal, and the result 
is an arrayed <comparison>( see Section 6.2.5). 

If the type of the <arith exp>s is FIXED, VECTORF, or 
MATRIXF, and the scaling of both <arith exp>s is defined, 
then the scalings must be equal. 
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6 . 2.2 


A bit comparison is a comparison between two bit 
expressions. 


SYNTAX: 



SEMANTIC RULES: | 

1. If the lengths of the operands are the same, their (j 

values are equal if and only if they have identical bit 
patterns . 

2. If the lengths of the operands differ, the <bit exp> 
of shorter length is left padded <»ith binary zeroes 
to match the length of ° the longer before comparison 
takes place, 

3. If one or both of the <bit exp>s are arrayed, then the 
result is an arrayed <comparison> (see Section 6.2.5). 


6-18 





6 .2,3 Cha/utct 2 A Compa/uuom i 


A character (k^parison is a comparison between two 
character expressions. ^ 


SYNTAX t 


dhmrnm comp$n»on 


NOT< 


comparison 


NOT> 


charoxp 


charoKp 


•xampw: 


SEMANTIC RULES: 


The two sttings are compared left’-to-right through as 
many characters as are contained in the shorter string. 

If a difference in any character is detected, the value 
,of the comparison is determined by the internal 
character representations of the differing characters 
(n.b. this is machine dependent) . 

If the shorter string is identical to the longer one \ 
truncated to be the same length as the shorter, then 
it is less than the longer one. 

If one or both of the <char exp>s are arrayed then the 
result is an arrayed <comparison> (see Section 6.2.5). 
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,6 .1,4 S^AuctuAe. Compa/Uson6 . 


A structure comparis4n is a comparison between two 
structure expressions* 


SYNTAX: 


(? 


S ' 




SEMANTIC RULES; 

1. The tree organizations of both <structure exp>s must be 
identical in all respects. 

2. The number of copies possessed by each <structure exp?' 
must be the same. If the number of copies is greater than 
one, then the following holds: 

• if thel^'comparison> operator is =, the result is TRUE^ 
only yl xt is TRUE for all copies. 

• if thL <comparison> operator is (NOT=) , the result 

is TRUE if it is TRUE for at least one pair of corresponding 

copies. V 9 
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16 . 2.5 


\ 


■ ti- 

Compaxiions beMtie.&n AH/iayzd OpzAatxcU. 


JV <cdmparison> of one of the forms described may have 
arrayed operands. When one or both of the operands is arrayed, 
the <comparison> operators are restricted to » and "•» (NOT*) . 

In any arrayed <comparison> , the following must be true. 


SEMANTIC RULES : ^ 

1. If one of the two operands of a <comparisoh> is arrayed 
then evaluation of the <comparison> using the unarrayed 
operand and each element of the arrayed operand is 
implied. 

2. If both of the operands are arrayed, then both operands 
must have the same array dimensions. Evaluation of the 
operation for each of the corresponding elements of the 
operands is implied . 

^ 3. The result Of an arrayed <comparx]5on> ds unarrayed . If 

the operator is = then the resUdt is TRUE~bnly if it is 
TRUE for all elements of the ^comparison> . If the 
operator is (NOT*) then the result is TRUE if it is 
TRUE for at least, one element of the <comparison> . 





SEMANTIC RULES: , 

1. An < event exp> is a sequence of <event operand>s separated 
by "a subset of bit operators . An <event exp> may not be 
arrayed, 

2. The syntax diagram for <event exp> produces a sequence 
extensible on the right. Any sequence produced is not 
necessarily to be considered as evaluated from left to 

,, right. / The order of evaluation of each infix operation 
is dictated by operator precedence: ;! 
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Operator \ 

Precedence 


FIRST 

AND, & 

1 

OR, 1 

2 ^ ___ 


LAST 


It two operations with«the seune precedence follow each 
other, they are evaluated from lef%;yto right. 

3. The operators AND (s) and OR (|) denote logical inter- 
section and union /respectively . ' 

An <event operand> appearing in an <event exp> has the 
following form. 


SYNTAX: 



f SEMANTIC ROLES: 

1. An <event operands may be an event variable, an <event exp> 
enclosed in parentheses , or a <process-event name>, in 
which case it is the name of a program or task event. 

2. The arrayness of any <event var> must have been removed 
by suitable subscripting (see Sections 5 .3 .3 and 5. 3 .4) , 

3. The <event operand> may be optipnally prefaced by the 
logical complementing operator NOT (*’) . 

4. If the <process event name> used as an event operand is 
that of an external PROGRAM, then a <PROGRAM template> must 
be included, in the compilation unit. The < process event name> 
for a TASK block is defined by the occurrence of the TASK 
block within a PROGRAM block . 
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6.4 Normal Functions. 

C' 

Sections 6.1.1 through 6. l^ 3 have made references to 
normal functions which may appear as operands in various types 
of <expression>. Normal functions comprise all those functions 
which are n^ conversion functions # and fall into two classes: 

e "built-in" functions defined as, part of the HAL/S 
language ; 

• "user-defined" fiinctions destined by the presence 
of < function iailoc3c> 3 in <compilation>s. (X, 

The manner of invoking each class Of function “is essentially 
the same. ■' -■ " 


SYNTAX: 


normal 
V (unison ^ 


normal function 



axampla: 

V SIN (2 X) 


SEMANTIC RULES ; 

1. <label> invokes execution of a function with name < label >. 

■* 

2. If <label> is a reserved word which is a ^built-in function 
name then that built-in function is invoked. A list of t 
built-in function names is given in Appendix C. 

Q 

3. If a <function block> with name <label> appears in, such a 
name scope that <label> is known to the invocation , then 
that block is invoked. 


If no such <f unction block> exists , then the <function block> 
is aiSsumed to be external to the ,<compilation> containing 
the invocation. A <function template> for that <functioh 
block>" must therefore be present in the <compilation> 

(see Section 3,6). 

if a < function block> is declared inside a DO. . .END 
group , it may only be invoked by a < normal function^ call 
contained in the same DO. . .END group. 





5 . 


6 . 


7. 


The type of the < normal fun1ction> must be appropriate to 
the type of the < expression > containing it (see Sections 
6.1.1 through 6.1.3). ='• 


Each of the < expression> s in the syntax diagram is an 
"input argument" of the function invocation. Input a; 
ments are "call-by -reference" or "call-by-value" l. 


Each input argument of a <normal function^ must match the 
corresponding input parameter of the function definition^ 
exactly in type, dimension, and tree organization, as 
applicable, except for the following relations: 


124 




•i 


■ vj 

precisions need not match, precision conversions are allowed; 


8 - 


9. 


the lengths of bit ^^^g\ments need not match; 

• character arguments must be declared CHARACTER (*) ; 

O ■' 

• implicit integer to scalar and scalar to integer 
conversions are allowed; 

• implicit integer and scalar to character conversions 

/are allowed. . " 

Adaitionally, if the parameter is of type FIXED, VECTORF 
oiCmatRIXF, and the scaling of both the input argument and 
formal parameter are defined, they must be equal. 

Input arguments may be viewed as being assigned to their 
I respective input parameters on invocation of° the function. 
\The rules applicable in the above relaxations thus parallel 
the relevant assignment rules given in Section 7.3. 

,\ 

If the appearance of an invocation of A^user-def ined func- 
tion precedes the appearance of its lif unction block> , 
the name and type of thfe function mus'1; be declared at the 
beginning of the containing name scope (see Section 4.6). 

Special considerations relate to arrayed input arguments 
to the <normal function> . If the corresponding input 
parameter is arrayed, then the arraynesses must match in 
all respects. In this case, the function is invoked once. 
If the corresponding parameter is not arrayed, then the 
arrayness mu^t match that of the <expression> containing 
the function. In this case, the <normal function> is 
invoked once for each array element. 


(154 


14 7 


1 See Section 7.4 

2 the parameter specifications for built-in functions is part 
of the f ormal def initiouj given in Appendix C. 
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example: 


ADD: 


Note: 


DECLARE X ARRAY(4) SCAUR; 


ixi - SINaXl); 

RJNCTION IP) SCALAR; 

DECURE P ARRAY(4) SCAUR; 

• , 0 
o 

RErdRN 

CLOSE ADD; 

* 
ft 
ft 

ixi - IXl + ADDIIXI); — 

• ... / 


SIN evaluated once 
for each element of X 


I 


f ADD evaluated once 
only; formal parameter 
P has same arrayness 
as argument X. 

[ADD must be defined 
before its invocation) * 


I I enclosing a variable name indicates that it has 
been declared to be arrayed. <> 





6.5 Explicit Type Conversions. 

The limited implicit, type converdions offered by,HAL/^ 
are described elsewhere in this Specification (see Sections 
6.1.1 and 7.3). HAL/S contains a comprehensive set of 
function** like explicit convcersions , some of which also have 
the property of bein? able to shape lists of arguments into 
arrays of arbitrary dimensions. For this reason# conversion 
functions are sometimes referred to as "shaping functions". 
HAL/S contains conversion functions to integer, scalar, vector, 
matrix, bit and character types. JJ 







6.5.1 A^fimettc ConveAA-con FunatcoM 

<i=> 

Arithmetic conversion functions include Conversions to 
integer, scalar, fixed, vector, and matrix types. 

SYNTAX: 


arithmetic conversion function 



INTEGERo o(4#ltJ) 


GENERAL SEMANTIC RULES; 

1. The keyword INTEGER, SCALAR, FIXED, VECTOR, VECTORP , 

MATRIX, or MATRIXF gives the result type of the conversion. 

2. The con^rsion keyword is optionally followed by a 
<precision> specifier giving the precision of the result 
(see Section 6.6), by a <scaling> specifier giving the ■ 
scaling to be performed during conversion (see Section 6.7) 
and by a <subsbript> specifying its dimensions. 
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3. The conversion has one or more < expression >s as arguments. 

The total number of data elements implied by the argument (s) 
are shaped according to well-defined rules to generate ,^he 
result. The data elements in each <expression> are \j 
unraveled in their "natural sequence"!. The result <Sf 
doing this for each argument in turn is a single linear 

V string of data elements. This string is then reformed or 
"reraveled" to generate the result. 

4. Any <expression> may be preceded by the phrase <arith exp>#, 
where <arith exp> is an unarrayed integer or scalar 
expression computable at compile time (see Appendix F . ) . 

The value of <arith exp> is rounded to the nearest integer 
and must be greater than zero. It denotes the number of 
times the following <expression> is to be used in th^^ 
generation of the result of the conversion, 

5. The nesting of <arith conversion>s is subject to implemen- 
tation dependent restrictions. 

6. In the context of an <arith conversion>, integers, scalars, 
vectors, and matrices have a defined scaling of 20., Ail 
<expression>s with defined scalings must have the same 
sealing.- 

SEMANTIC RULES (INTEGER, SCALAR, AND FIXED): 

1. If INTEGER, SCALAR, or FIXED are unsubscripted , and have 
pnly one unrepeated argtiment of integer, scalar, fixed, 
bit, or character type, then if the argument is arnayed, the 
result of the conversion is identically arrayed. 

2. If INTEGER, SCALAR, or FIXED are unsubscripted, and Rule 1 
does not apply, then the result of ths conversiQn is a linear 
(1-dimensional) array whose length is equal to the total 
number of data elements implied by the argument (s). 

3. If INTEGER , SCALAR , or FIXED are subscripted, the form of 
the < subs crip t> must be a sequence of <arithexp>s separated 
by commas. The number of < arith exp> s is the dimensionality 
of the array produced , Each <arith exp> is an unarrayed 
integer or scalar expression computable at compile tiroe. 

Values are rounded to the nearest integer, and must be greater 
than one. They denote the size of each array dimension pro- 
duced. Their product must therefore match the total number of 
elements implied by the argument (s) of the conversion. 

4. INTEGER, SCALAR, and FIXED may have arguments of any type 
(subject to general rule 6 above) except sfthcture. Type 
conversio^n proceeds agcording to the ■standard conversion rules 
set out in Appendix d‘. 


■See Section 5.5. 


5. The precision of the result is SINGLE unl/ess forced by the 

precision of a <precision> specifier. | ^ 

6. ’A <scaling> specifier is permitted on INTEGER and SCALAR only 

if all the <expression>s are composed of numbers, FIXEDs, 
VECTORFs, or MATRIXFs. ' 

7. When converting FIXEDs, MATRIXFs, and VECTORS, to INTEGERS, 
SCALARs, VECTORS, or MATRIXs, the scaling of the result of 
the conversion (if knovm) must be 20. 

SEMANTIC ROLES (VECTOR, VECTORF, MATRIX, AND Mj^TRIXF) : 

1. In the absence of a <subcript>y VECTOR or VECTORF produces 
a single 3-vector result; MATRIX or MATRIXF produces a 
sifigle 3-by-3 matrix resiilt. The number of data elements 
implied by the arguirient (s) omust therefore be equal to 3 
and 9 respectively . 

2. VECTOR, VECTORF, MATRIX, and MATRIXF qannot produce arrays 

of vectors and matrices, "Consequently, <subscript> may 
only indicate terminal subscripting, , , 

o . 

3. In VECTOR or VECTORF, the <subscript> must be an <arith exp>. 

is an unattayed integer or scalar expression 
computable at compile time (see Appendix F) . Its value 
is rounded to the nearest integer, and must be greater than 
one. It denotes the length of the vector produced by the 
conversion. It must therefore match the total number of 
data elements implied by the argument (s) of the conversion. 


4 . In MATRIX or MATRIXF , the form of the <,subscripfc> must be 


<arith exp> , < arith exp> 


Each <arith exp> is an unarrayed integer or scalar expression 
computable at compile time. Values are rounded to the nearest 
integer,, and must be greater than one. They denote the row 
and column dimensions^ respectively; of the matrix produced by 
the conversion. Their product must therefore match the total 
number of data elements implied by 1g|ie argument (s) of the 
conversion. 


5. VECTOR, VECTORF, MATRIX, and MATRIXF may have arguments of 
integer, scalar, fixeds, vector, and matrix type only. 

6.. The precision of the result is SINGLE unless forced by the 
presence of a <precision> specifier. 

I 7. A <scaling> specifier is permitted on MATRIX and VECTOR only 
if all the <expression>s are composed of numbers, FiXEDs, 
VECTORS, or MATRIXs, 
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examples: 


0ECLARE"y ARRAY(2,3) SCAUR, ° 

: V VECTORO); 

* : & 

INTEGERdX^!^, 

result is 2,3 array of integers 

INTEGERdXl. (Xl) 
SCAUR(V) /I 

result is linear 12*array of 
integers 

O 

result is linear 3^array of 
scalars 

INTEGER, J2#[X]| 
2,0 

^ result is 2,6 array of integers* 

MATRIXI3#V) 

result is 3 by 3 matrix, each row 
being equal to V 

VECTOR^dXl) 

vector of length € 

Note; A variable enclosed 
arrayed 

in I ] denotes that it is 


For example: 

Let [X] * [J 


2 3 

5 6.] 


Argument 2# [X] is "first unraveled 
[ 1 2 3 4 5 6 1 2 3 4 5 6 ] 


Linear string is. then „ "reraveled" into 2x6 array: 

■■'O' 

fl 2 3 4 5 6l 

11 2 3 4 5 6J 
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6.5.2 Thz Bit Conv&ui.on Function. 


Conversion to bit type is carried out by the BIT 
conversion function. 


SYNTAX: 



GENERAL SEMANTIC RULES: „ 

■ ■ ' ' . . : . . . 

1. The keyword BIT denotes conversion to bit type. 

2. The conversion has one argument of integer, scalar, fixed, 
bit or character type. If the argument is arrayed, the 
result of the conversion is identically arrayed, 

SEMANTIC RULES (without radix ) : 

1. Conversions of the argument proceed according to the 

standard conversion rules given in Appendix D, The 
resulting bit string is of mai35nurac-J.ength for the 
implementation and the significant <§fata is right ^ 

justified within the word, 

2. <subscript> represents component sulsscripting upon the 
results of the conversion. <subscript> has the same 
semantic meaning and restrictions in the current context 
as it does in the subscripting of bit <variable>s (see 
Section 5.3.5). 
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SEMANTIC RULES (with <radix>) : 

1. The single argument of the <radix> version of the BIT 

conversion must be a <char exp> , <radix> specifies a = 
radix of conversion, and has one of the following syntac- 
tical forms: 


@HEX 

@DEC 

@OCT 

@BIN 


(hexadecimal) 

(decimal) 

(octal) 

(binary) 


2. The <char exp> must consist of a string (or array of 

strings ) of digits legal for the specified < radix> ; ( 

otherwise a runtime error occurs. The conversion generates' 
the binary representation of the digit string . ' 

3. During conversion, if the length of the result is too 

long to be represented in an implementation, left truncation 
occurs. 


examples: 


DECLARE X ARRAY(2,3) SCAUR; 


B1T(IX1) 


result is a 2> 3 array pi bit strings 


BITj i^(tXI) 


same as above except that only bits 
1 through 16 of each array element 
are taken 

result is bit pattern of hexadecimal 
digits represented by argument 


Note: A variable enclosed in [ J denotes that it is 

arrayed 




i.JWi 


6.5.3 The CfufAacteA Cq^ew-con Functio^, 

0 

Conversion of character type is carried out by the 
CHARACTER conversion. 

SYNTAX: ^ 


char 

eotmnion 


CHARACTER CONVERSION FUNCTION 




'$>« . ■ I KtNn« I' ( I )— ^ I wlMolpl 




GENERAL SEMANTIC RULES ; 


1. The keyword CHARACTER denotes conversion to character 
type . 

2. The conversion has^ne argument of integer, scalar, fixed 
_ bit, or characterj^pe , If the argument is arrayed, the 

result of the coWersion is identically arrayed. . 






SEMANTIC RULES (without <radxx>) ; 


1-. Conversion of the argument proceeds according to the 
" standard conversion rules given in Appendix 0. 

2. <subscript> represents con^onent subscripting upon the 
results of the conversion. It has i^e same semantic 
meaning and restrictions in the current context as it 
does in the subscripting of character <variable>s (see 
Section 5.3.5) , 


0 



I 


i 


3. A <scaling> specification is allowed only if the 
<expression> is of type FIXED. 

0 

SEMANTIC RULES (with <radix>) s l? 


147 


1. The single argument of the <radix> version of the 
CHARACTER conversion must be a <bit exp> . <radix> 
specifies a radix of conversion# and has one of , the 
following syntactical forms: ^ 


SHEX (hexadecimal) 

0DEC (decimal) 

@QCT (octal) 


0BIN 


(binary) 


2. The value of <bit exp> is converted to the representation 
indicated by the <radix>, left padding the value with 
binary zeroes as required. The result is a character 
string consisting of the digits of the representation i 




] 




examples: 


DECLARE X ARRAY(2, 3) SCALAR; 


CHARACTERaxi) 
CHARACTER^dXI) 
CHARACTERgpg^(B IN '101101 ' ) 


result is a 2,3 array of character 
strings 

ffV 

same as above except that only the 
second character of each array 
element is taken 

p 

result is decimal represehtation of 
the bit pattern of the argument 


Note: A variable enclosed in [ ] denotes that it is 

arrayed 


1 ; 





6.5,4 me SUBBIT Pizudo-vaxiablz. 


The SUBBIT pseudo-variable .is a way of making the 
bit representation of other data types directly accessible 
without conversion. It may appear in an assignment context 
(see Section 7.3) as well as part of an <expression> . It 
rs denoted, syntactically by <bit pseudo-var>. 

SYNTAX: 


SUBBiT pttudo-variablt 


/ bit \ 

.pmodO'W . 


Vvariablf 


^>—4 subscript |— 



txampit; 


SUBBIT, TO e 


SEMANTIC RULES X 

1. The keyword SUBBIT denotes the pseudo-variable. 

2. SUBBIT has one argument oniy. If it appears in an 
assignment context, the argument must be a <variable>. 

If it appears as an operand of a bit expression, the 
argument must be an <expression>. 

)) 

3. The argument may be of integer, scalar, fixed, bit, 
or character type, and may optionally be arrayed. 

4. The effect of SUBBIT is to make its argument look like 

an operand of bit type. (If the argument is arrayed, then 
it looks like i^n a«;|iyed bit operand.) 

5. <subscript> represents component svibscripting upon the 
pseudo-variable. It has the same semantic meaning as if 
it were subscripting a bit variable (see Section 5.3.5). 
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6. The length of the argument in bits may in some implemen- 
tations be greater than the maximum length of a bit 
operand. ' Let the maximum length of a bit operand be 
N bits. If SUBBIT is unsubscripted, only the M leftmost 
bits of the machine representation of the data-type of 
the argument are visible* If the representation is less 
than N, the number of bits visible is equal to the 
length of the particular data argument. 

o 

Partitioning subscripts of SUBBIT may m 2 dce between 2 and 
W bits from the representation of the argument type 
visible at any time Ci*e* the partition size is < fJ.) 

The partition size must be known at compile time. If 
the representation is less than the specified partition 
size, binary zeros are added on the left. 

In an assignment context, SUBBIT functions may not be 
nested within SUBBIT functions. Neither may they 
appear as assign arguments, or in READ or READALL 
statements. 


example; 

© 


DECLARE P SCALAR DOUBLE; 
» 




bits 33 through 64 of the machine 
representation of P look like a 32-bit 
bit variable 


bits 1 through 32 are invisible 



6.7,^. Smmofitj Afigument Tijpu. 


The asterisks in the following table indicate the 
legal argument types for each conversion function* 


Conversion 

Fiinrllon I INTEGER 1 SCALAR 


INTEa§R 


SCALAR 


FRACTION 


VECTOfI 


VECTORF 


MATRIX 


MATRIXF 


BIT 


ARGUMENT TYPE 


VECTORF I MATRIX IMATRIXF | BIT 


iKBsaaii 


* 

* 

* 

; 

* 

* 

* 

* 

3>Jj 

* 

* 


* 


* 

s(c 


CHARACTER 


* 


* 


* 


CHARACTER 


SUBBIT 

























































































SEMANTIC RULES: 


1. If <precision> is specified as'^a subscript to an 
<arith operand> (see Section €.1.1)^ a conversion to 

— the precision specified takes place. 

2. If <precision> is specified as a subscript to an 
<arith conversion> then the result of the conversion is 
generated with the indicated precision. 

3. If referring to integer type, SINGLE implies a" halfword, 
and DOUBLE a fullword. The interpretation is machine 
dependent. 


0 
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6.7 Scaling 

FIXEDs. VECTORFs, and MATRIXFs contain values between 
minus one and one. It is the programmer's responsibility 
to define appropriate scale factors for all fractional objects 
and to explicitly specify all scaling operations. The scaling 
specifier is used to define the scale factor associated with a 
FIXED, VEGTQRF, or MATRIXF, and 'txT Specify any regUired 
changes in that scaling. Scaling specifiers may be used as 
attributes in declarations (Section 4.5), to specify changes 
in the scaling of literals, PlXEDs, VEGTORFs, and MATRIXFs 
(Section 6.1.1), and to specify changes in scaling while 
performing conversions (Sections 6.5.1. and 5.3) • 


U 


SYNTAX; 



SEMANTIG RULES : 

1. <arith exp> must be of either integer or scalar type. 

2. The form @<arith exp> specifies a scaling of 

When used as an attribute in a declaration, it defines the 
scale factor of the associated objects to be exp>^ 

When used as an operator, it specifies a change in the scaleO 
factor by 2 <arith exp> which is equivalent to a multiplica- 
tion by 2 -<arit exp>. , ^ > 

3. The form @@<arith exp> specifies a sealing of <arith exp> . 

When used as an attribute in a declaration, it defines 

the scale factor of the associated objects to be <arith exp>' . ^ 
When used as an operator-;? it specifies a change in the scale 
factor by arith exp which is equivalent to a multiplicatidn 
by <arith exp>“^. 
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7. EXECUTABLE STATEMENTS 


Executable statements are the building blocks of the 
HAL/S language. They include assignment, flow control, real 
time programming, error recovery, and input/output statements. 
Syntactically a statement of the above type is designated by 
<statement>. The manner of its integration into the general 
organization of a HAL/s' compilation was discussed in Section 3 




m 


Basic Statements. 


All forms of <statement> except the IP statement 
and certain forms of the ON ERROR statement (Section 9.1) 
fall into the category of a <basic statement>. 

SYNTAX: ® 


tttttimnt 


basic sutamcnt 


Any <basic statement>, unless it is imbedded in an IF 
statement or ON ERROR statement, may optionally be labelled 
with any number of <label>s. Not all forms of <basic 
statement> are described in this Section. Real time 
programming statements are described in Section 8 f error 
recovery statements in Section 9, and input/output statements 
in Section 10 . 






7.2 The IFStatenienf. 

( 

The IF ftiitenent provides for the unconditional exec 
tion of se^ients of HAL/S code. 0 




SYNTAX; 



SEMANTIC RULES: 

1. The IF statement, unless it is imbedded in another 
IF statement or in an ON ERROR statement, may 
optionally be labelled with any number of <label>s. 

2. The option to label the <statement> or <basic statement> 
of an IF statement is not disallowed. However, such 
labels may only be referenced fay REPEAT or EXIT state- 
ments within'^the (compound) <statement> or <basic statement> 
thus labelled. 

3. If <bit exp> appears in the IF statement, then it must 
be boolean (i.e. of 1-bit length). 

4. If the <condition> or <bit exp> is TRUE, then the < statement 
£2 or <basic statement> following the keyword THEN is executed. 

If <bit exp> Is arrayed, then it is considered to be TRUE 
only if all its array elements are TRUE. Execution then 
proceeds to the <statement> following the IF statement. 
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5. If the <condltion> or <bit exp> is FALSE then the 

<statement> or <hasic statement> following the keyword 
THEN is not executed. If the ELSE clause is present 
then the <statement> following the keyword ELSE is 
executed instead, and then execution^ proceeds to the 
<statement> following the IP statement. If the ELSE 
clause is absent, execution merely proceeds to the next_ 
<statement>. '' 

NOTE: If the ELSE clause is present, a <baSic statement> 

father theun a <statement> precedes the keyword ELSE. A 
nested IF statement therefore canhot appear in this position, 
thus preventing the^ well-known 'dangling ELSE* problem. 








7. 3 Tlie Assignment Statement. 


The assignment statement is used to change the current 
value of a <variable> or list of <variable>s to that of an 
expression evaluated in the statement. 


SYNTAX: 


MSignment ttetemtfit 



•xampla; 


ETA, XAH»A « l^MBpA + 1,' 


GENERAL SEMANTIC RULES; 

1. <variable> may not be an event variable or an input 
parameter of a procedure or function block. 

2. The effectiv^^ order of execution of an assignment state- 
ment is as follows: 


• any subscript expressions on the left-hand side are 
evaluated; 

o 

• the right-hand side <expressi)^n> is evaluated; 

• the values of the left-hand side <variable>s are 
changed. 


If the <expression> on the right-hand side is array^Jfe,. 
then all the <variable>s on the left-hand side must be 
arrayed. The number of dimensions of arrayness on each 
side must be the same, and corresponding dimensions on 
either s file must match in size. 




^ ' ii 

4. If the <expression> on the right-han(| side is not arraj^ed 
then it is still possible for one or more <variable>s'’o^ 
leftrhand side to be arrayed. If more than one <variable> 
is arrayed, the arraynesses must match in the sense of 
General Semantic Rule 3, above. The single unarrayed value 
will be assigned to every element of arrayed targets# 


Generally, the^ype of the <expression> must match the 
types of the <variable>s on the left-hand side. Specific 
exceptions to this r^le are listed below. The type of 
an assignment is taken to be the same as the type of the 
<variable> whose value is being changed. 

‘'■■o 

If a variable has a RANGE attribute then the runtime value 
of the expression must fall within the range. ^An out of 
range assignment may lead to compile time and/or runtime,^ 
error messages— its effect is undefined. 


u 


SEMANTIC RULES (integer and scalar assignments) ; * 

1 . The following implicit type conversions are allowed 
during assignment: 

. -r ..- Assigxonent of an integer <expression> to a scalar 
<variable> is allowed; 

• Assignment of a scalar <eXpression> to an inteaer 
<variable> is allowed. 

2. If the left- and right-hand sides of a scalar assignment 
have differing precisions, precision conversion is freely 
allowed. Conversion from DOUBLE to SINGLE precision 
implies truncation of an implementation dependent number 
of binary digits from exponent, mantissa, of both. 


SEMANTIC RULES (fixed assignments): 

1. Both the <variable> and the <expression> must be of type FIXED. 

2. If the scaling of both the <variable> and the <expression> are 
defined they must be equal. 

3. If the <variable> and the <expression> have different ''precisions, 
the value of the <expression> is truncated on the right or zero 
extended on the right to conform with the precision of the 
<variable>. 
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SEMANTIC RULES (vector and matrix assignments) : 

1. The <expression> must normally be a vector or matrix 
expression with the same type and dimension (s) as the 
<varlable>s on the left-hand side. One relaxation of 
this rule is permitted. Matrix or vector <variable>s may 
be set null by specifying literal zero for the <expression> . 

In this case only, both matrices and vectors of any 
dimension (s) may appear mixed in the list of <variable>s. 

O f 

2. If the left‘s and right-hand sides of an assignment have I | 

differing precisions, precision conversion is freely allowed, 1 147 
according to the {Semantic rules for scalar and fixed as- I 

signments given above. o * 

3. For VECTORP and MATRIXF assignments, if the scaling of both 
the <variable> and the <expression> are defined they must be 
equal. 


SEMANTIC RULES (bit assignments) : 

1. If the length of the bit <expression> is unequal to that 
of the left-hand side bit <variable> , then the result of 
the <expression> is left-truncated if it is too long, or 
left-padded with binary zeroes if it is too short. 

2. The effect of a left-hand side < variable^ being a 
< bit pseudo-var> is described in Section 6.5.4. 


SEMANTIC RULES (character assignments) ; 

1. Assignment of an integer or scalelr <expression> to a 
character <variable> is allowed. During assignmenj/ the 
integer or scalar value is converted to a character string 
according to the conversion formats given in Appendix D, 

2. If < variable!* is a character variable with no component 
subscripting,, then: 

• If the length of the <e3Ct3ression> is greater than the 
declared maximum length of the <variable>, the 
<expression> is right-truncated to that length. The 
<variable> takes on its maximum length. 

• If , the length of the <expression> is not greater than 
the declared maximum length of the <variable> , then 
<variable> takes on the length of the <expression> . 
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3. If <varlable> is a character variable with component sub-^ 
scripting then: 

-O 

0 If the length of the <expression> is greater than the 
length implied by the component subscript, then it^^^ 
right-truncated to the implied length. 

• If >^e length of the <expression> is less than the 
length implied by the component subscript, then it is 
right-padded with blanlcs 'cb the implied length. 

After assignment the <variable> takes on the length 
..implied by the upper index of the component subscript, 
or retains its original length, whichever is the 
greater. If the upper index of the subscript implies 
a length greater than the declared maximum for that 
<Variable> , right-truncation to the maximum length 
occurs. ° 

If the lower index is greater than the length of the 
<variable> before assignment, then the intervening 
gap is filled with blanks. 




SEMANTIC RULES (structure assignments) ; 

0 ' ' ' '' . : : = . . . . . 

1. <expression> can only be a <structure exp>. The tree° 
organization of the structure operands on both sides 
of the assignment must match exactly in all respects. I | 

The sense in which tree organizations of two structures e 

are said to match is described in Section 4.3. 
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7.4 The CALL Statement. 


The CALL statement is used to invoke execution of a 
procedure. The PROCEDURE block may be in the same <compilation> 
as the CALL statement or external to it. 


SYNTAX: 


CALL ttaMiiMtit 



SEMANTIC RULES : 

1. CALL <label> invokes execution of a procedure with name 
<label> . 

2. If a <procedure block> with name <label> appears in such 
a name scope that <label> is known to the CALL statement, 
then CALL <label> invokes that block. 

5. If a ^procedure block> is declared inside a DO. ..END 

group,, it may only be invoked by a CALL statement contained 
in the same DO... END group. 



3. If no such <procedure block> exists, then ,^the <procedure 
hlock> is assumed to be external ±o the <compilation> 
containing the CALL statement, A^^<procedure template^ 
for that <procedure block> must therefore be present in 
the <compilation> (see Section 3.6) • 

4. Each of the <expression>s is an "input argument" of the 
procedure call . 

5. Each of the <variable>s is an "assign argument" of the 
procedure call. Only assign arguments may have their 
values changed by the procedure. If <variable> is sub- 
scripted, it must be restricted in form to t^e following; 

• No component sxibscripting for bit and character types . 

• If component subscripting is present, <variable> must 
be subscripted so as to yield a single (unarrayed) 
element of the <variable> . 

• If no component subscripting is present, but array 
subscripting is, then all arrayness must be subscripted 
away. 

6. Assign arguments are "call-by-reference". Input .arguments 
are either “eall-by-reference" or "call-by-value"^. 

7. Each assign argument must match its corresponding procedure 
block assign parameter exactly in type, precision, dimension 
arrayness, structure tree organization, and DENSE and 
REMOTE attributes, as applicable. CHARACTER lengths 

are an exception; they must be declared CHARACTER (*). 

The reason is that character types are of varying length 
and the actual length is available at execution. If an a 
assignment argument has the LOCK attribute, then the 
following must apply: 

• If it is of lock group N, then the corresponding assign 
parameter must be of lock group N, or *. 

• If., it is of lock group », then the corresponding ’■ 
parameter must also be of group *. 


In this context "call-by-reference" means the arguments 
are pointed to directly. " Cal 1-by- value" means the 
value of an input argument, at the invocation of a 
procedure, is made available to the procedure. 


1 




8. Two types of indentlfiers may not be used as assign argu^ 
ments of a CALL statement when they are part of structure 
variables and have a DENSE attribute. They are integer 
type identifiers with a specified RANGE attribute and bit 
\\ type identifiers. Ail other types of structure terminals 

with the DENSE attribute may be used as ASSIGN arguments. 
See Sections 4 . 3 and 4 . 5 for further explanation of the , 
DENSE attribute. Note, however, that an entire structure 
with the DENSE . attribute may be passed provided that 
template matching rules are observed. 
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9. For input arguments, the following Te^iaxations of 
rules 7 and 8 are permitted: 

I ' I 0 = ■' 

^ precjisions need not match; ^ 

^ the lengths of bit arugments need not match; 

I • CHARACTER ag'guments must be declared CHARACTER!*) ; 

• implicit integer to scalar and scalar to integer , 

conversions are allowed; •"-> 

• Implicit integer and scalar to character conversions 
are allowed; 

• matching of the attributes, ..DENSE and REMOTE is not 
required. 

Input arguments may be viewed as being assigned to their 
respective input parameters on invocation of the procedure. 
The rules applicable in the above relaxations thus 
parallel the relevant assignment rules given in 
Section 7.3 . 

147 | 10.' If the formal parameter and actual argument are both 
I FIXEDs, VECTORS, of MATRIXs with defined scaling, 

I then the scalings must be equal. 

11. If an assign argument is a structure terminal or a 

minor structure node (but not if it is a major structure) 
and if the structure possesses multiple copies, then the 
number of copies must be reduced to one by subscripting. 


example: 


STRUCTURE Z: 

r ^ 

2 C CHARACTER (so), 

2 B VECTOR, 

1 D INTEGER; , 

DECLARE ZZ Z-STRUCTURE(20); 


CALL X ASSIGNCzZ, ZZ.A, ^Z'A.B, ZZ-A^); 

legal illegal legal 
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7.5 The RETURN Statement. 


The RETURN statement: is used to cause return of 
execution from a TASK, PROGRAM, PROCEDURE, or FUNCTION block. 
In the case of the FUNCTION block it also specifies an 
expression whose value is to be returned. 


SYNTAX ; 



& 

GENERAL SEMANTIC RULES : 

1. The effect of the RETURN statemeht is to cause normal 
exit (return of execution) from a TASK, PROGRAM, 
PROCEDURE, or FUNCTION block. (Also see the CLOSE 
statament. Section 3.7.4). 

2, <expression> may only appear in a ^TURfj statement of 
a <function>. its value is the returned value of the 
function, and is evaluated prior to returning. 
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3. <expression> must match the function definition in type 
ii and dimension, with the following exceptions: 

I , : ■' I 

I ° ^ the ilengths of bit expressions need not match; 

i ' 

^ « the lengths of character expressions need not match; 

) O . f' 

• implicit integer to scalar and scalar to integer 
conversions are allowed; 

• implicit integer and scalar to character conversions 
are allowed. 

The return of the function values may be viewed as the 
assignment of the <expression> to the function name, (j 
The rules applicable in the above exceptions thus 
parallel the relevant assignment rules given in Section 7.3. 

1 4.; if the <expression> and the function are both FIXEDs, 

I VEGTORFs, or MATRIXFs with defined scalings, tiie scalings 
must be equal. 

i 

5. <expression> must always appear in RETURN statements of 

<function block>s. Execution must always end on logically 
reaching a RETURN statement of such a block, and not by 
logically reaching the delimiting CLOSE stat< 3 ment . 






DO . . * END statement group 


procedure block 


f basic > 
k statement > 


function block 


update block 


do statement 


end statement 


example: 


DO WHILE J> 0; 


The DO. . .END statement group xs opened with a <dostatement> 
and closed with an <end statement>. In between may appear 
any number of <statement>s interspersed as required with 
FUNCTION f PROCEDURE, or UPDATE blocks. The form of the 
<do statement> determines how the < statement >s within the 
group are executed . 
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7 . 6.1 The. VO Statement. 


O 

* 7he simple 00 statement merely indicates that the follow- 
ing sequence of <statement>s comprising the group is to be 
viewed as a single <basic statement>. The sequence is executed 
i once only. 0 


SYNTAX: 






o 


l.ft.l The VO CASE StcLtm&nt. 

The DO CASE statement indicates that in the following 
sequence of <statpment>s comprising the group, only one 
specified <statement> is to be executed. 

SYNTAX: 


00 CASE Statement 


•xainpit: 

ALPHA; DO CASE J -I; 


SEMANTIC RULES: 

1. <arith exp> is any unarrayed integer or scalar expression. 

The value of a scalar expression is rounded to the nearest 
integer before use. ^ ' 

2. Let the value of <arith exp> be denoted by K . If K is 

greater than zero , but not greater than the number of 
<statement>s in the group, then the ^statement> of 

the group is executed. 

3. If the value of K is, outside the range defined in Rule 2, 
and no ELSE clause appears in the DO CASE statement, 

then an error condition exists. The result of such 13 

an error is implementation dependent - 

4. If the value of K is outside the "range def ined in Rule 2 , 
but an ELSE clause does appear, the < statement > following 
the ELSE keyword is executed instead of one of those in the 
group . The option to label <stateraent> is not disallowed . 
However , such labels may only be referenced by EXIT or 
REPEAT statements within the (compound) <statement> thus 
labelled. 

5. The presence of any code block definition in the group of 
<statement>s does not change the fC-indexing of the <statement>s 
except for UPDATE blocks (which are considered as single 
statements) . 








7.6.3 


Tfte VO WHILE and UHTU Sta^ementi. 


The DO WHILE and UNTIL statements cause repeated 
execution of the sequence of <statement>s in a group until 
some condition is satisfied. 


SYNTAX: 



SEMANTIC RULES: 

1. There is no semantic restriction on <condition>. 

<bit exp> must be boolean and unarrayed (i.e., of 
1-bit length). The <condition> or <bit exp> is re- 
evaluated every time the group of <statement>s is 
executed. 

2. In the DO WHILE version, the group of <statement>s is 
repeatedly executed until the value of <coriditfpn> or 
<bit exp > becomes FALSE. The value is tested at the 
beginning of each cycle of execution. This implies that 
if <condition> or <bit exp> is initially FALSE the group 
of <statement>s is not exec*ited at all. 


W 
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In the DO UNTIL version, the group of <stateinent>s is 
repeatedly executed until the value of <condition> or 
<bit exp> becomes TRUE. The value is not tested before 
the first cycle of execution. On the second and all 
subsequent cycles of execution, the value is tested at the 
beginning of each cycle. Use of the UNTIL version there- 
fore guarantees at least one cycle of execution. 








O 
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7.6.4 The Vl&cAJite. VO FOR Statemnt. 


The discrete DO FOR statement causes execution of the 
sequence of <statement>s in a group once for each of a list 
of values of a "loop variable" . The presence of a WHILE or 
UNTIL clause can be used to cause such execution to be depend 
ent on some condition being satisfied. 


SYNTAX: 



SEM^;NTIC RULES: 

1. <arith var> is the loop variable of the DO FOR statenient. 
It may be any unarrayed integer, scalar, or fixed 
variable. The initial loop variable, determined after all 
required subscripting and NAME dereferencing, is used 
throughout . 

2. The maximum number of times of execution of the group of 
<statement>s is the number of <arith exp>s in the assign^- 
ment list. 

3. <arith exp> is an unarrayed INTEGER , SCALAR, Or FIXED 
expression. 
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4. FIXED may be used only if the < arith var > and all 

the <arith exp>s are fixed. If more than one of the^ 147 
FIXEDs in the DO statement has a defined scaling, the 
scalings must be equal. ^ 

5. At the beginning of each cycle of execution of the group 
the next < arith exp> in the list (starting from the left- 
most) is evaluated and assigned to the loop variable. The 
assignment follows the relevant assignment statement rules 
given in Section 7.3. 


6 . 


7. 


8 , 


Use of the WHILE or UNTIL clause^, causes continuation of 
cycling of execution to be dependent on the value of 
<condition> or <bit exp>. 

. ■- ■ n . 

There is no semantic restriction or <cond4tion> . 


<bit exp> must be boolean and unarrayed (i.e. of 
l-bit length). The <condition> or <bit exp> is re- 
evaluated every time the group of <statement>s i^ 
executed, /y 



If the WHILE clause is used, cycling is ^ 

abandoned when the value of <condition> or <bit exp> 
becomes FALSE. The value is tested at the beginning of 
each cycle of execution after the assignment of the loop | 

variable. This implies that if <condition> or <bit exp> | 

is FALSE prior to the first cycle of execution of the group . ] 

then the group will not be executed at all. | 


9. If the UNTIL clause is used, cycling of execution is 
abandoned when the value of <condition> or <bit exp> 
becomes TRUE. The value is not tested before the first 
cycle of execution. On the second and all subsequent 
cycles of execution, the value is tested at the beginning 
of each cycle after the assignmen^t of the loop variable. 
Use of the UNTIL version thefefoi'b always guarantees at 
least one cycle of execution. 



7.6.5 The ItefLOtwe VO FOR STatment. 


The Iterative DO FOR statement is similar in intent and 
operation to the discrete DO FOR statement, except that the 
list of values that the loop variable may take on is replaced 
by an initial value, a final value, and an optional increment. 


SYNTAX: 


/ do \ 

ittrativt 00 FOR itaitmtnt 

0 

^ SttUflMOt I 




arith var 


arith txp 


arlthaxp 


8Y H arith axp 


{^ILE 


condition 

bittxp 


axampit; 


DO FOR I » 1 TO 30 BY 2 UNTIL J < 0; 


SEMANTIC RULES: 

1.. <arith var> is the loop variable of the DO FOR statement. 
It may be any unarrayed integer, scalar, or fixed 
variable. The initial loop variable, determined after 
all required subscripting and JJAME dereferencing, is used 
throughout . 

2. Each <arith exp> is any unarrayed integer, scalar, or 
fixed expression. All are evaluated prior to the first 
cycle of execution of the group. 


ill 












FIXEDs may be used only if the <arith Vcur> and 
the <arith exp>s are fixeds. If more than one 
in the ^00 statement has a defined scaling, the 

scalings must he equal. When FiXEDs are used, 
BY clause must appear. ^ 


all 

FIXED 

the 


147 


4. If a BY clause appears in the DO FOR statement, the value 
assigned to the loop variable prior to the cycle of 
execution is equal to its value on the K-1^" cycle plus 
the value of <arith exp> following the BY keyword (the 
"increment") . 


5. Assignment of values to the loop variable follows the 

relevant assigni||ient rules given in Section 7.3. In 
particular, if the loop variable is of integer type, 
and an initial value or increment is of scalar type, the 
latter will be rounded to the nearest integer in the 
assignment process. The effect of the loop variable assign- 
ment is identical to that of an ordinary assignment state- 
ment: the loop variable will retain the last value computed 

and assigned when the DO statement execution is completed, 

I O . . 

6. After the value of the loop variable has been changed, it 
is checked against the value of the <arith exp> following 
the TO keyword (the "final value"). 

7. If the sign of the increment is positive, the next cycle 
is permitted to proceed only if the current value of the 
loop variable is less than or equal to the final value. 

8. If the sign of the increment is negative, the next cycle is 
permitted to proceed only if the current value of the loo^ 
variable is greater than or equal to the final value. 

9. If the WHILE clause is used, cycling of execution is 
abandoned when the value of <condition> or <bit exp> 
becomes FALSE. The value is tested at the beginning of 
each cycle of execution after the assignment of the loop 
variable. This implies that if <condition> or <bit exp> 

is FALSE prior to the first cycle of execution of the group, 
then the group will not be executed at all . 

10. If the UNTIL clause is used, cycling of execution is 
abandoned when the value of <condition> or <bit exp> 
becomes TRUE. The value is not tested before the first 
cycle of execution. On the second and all subsequent 
cycles of execution, the value is tested at the beginning 
of each cycle after the assignment of the loop variable. 

Use of the UNTIL version therefore always guarantees at 

least one cycle of execution. /(% 

(f 
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7 . 6*5 The EMf Statement. 


The END statement closes a DO. , .END statement group 


SYNTAX* 




ENO ttattmtot 


i 

/ «Kl \ 



© 








•xwnpl*: 



END LOOP; 


SEMANTIC RULES s 

1. If <label> follows the END keyword, then it must match a 
<label> on the <do statement> opening the DO... END group. 

2. The <end statement> is considered to be part of the group, 

in that if it is branched, to from a <statement> within the 
group, then depending on the form of the opening <do 
statement> , another cycle of execution of the group may 
begin. (The END statement closing a DO CASE is not counted 
as another case.) „ 
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7.J Other Basic statements. 


Othe^ <basic statement>s are the GO TO 
EXIT, and REPEAT statements. 


SYNTAX: 


basic 

statements 


GO TO, "null”, EXIT, and REPEAT statements 



W 5 >— ( label V— ' 

example: V.' ✓ 

ONE; DO FOR I * 1 TO 10; 

TWO: DO FOR ^ ^ 37 TO 43; 

IF B\j * false then repeat ONE 
END;' 

END; 


REPEAT 


SEMANTIC RULES; 

1. The GO TO <Xabel> statement causes a branch in execution 
to an executable statement bearing. ;the same <label>. 

The latter statement must be within the same name scope 
as the GO TO statement. A GO TO statement may not be 
used to cause execution to branch into a DO. s. END group , 
or into or out of a code block . 

2. The "null" statement (where no syntax except possihie 
<label>’S precede the terminating semicolon) has^; hb eff ect 
at run time. 
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3. The,i EXIT statement is legal only within a DO. . .END group, 

or within such groups nested. The ''%rm EXIT <led3e> controls 
execution relative to> the enclosing Db. ..END group whose 
<D0 statement > bears <labeJ> . The form EXIT controls 
execution relative to the innermost enclosing DO. . .END group 
Execution is caused to branch out of the DO. ..END group 
specified or implied, to the first executable statement 

after the group. 

h, 

4. The REPEAT statement is = legal only v/ithin a DO. . .END group 
opened with a DO FOR, DO WHILE, or DO UtJTIL statement, or 
within such groves nested. The form REPEAT < label > controls . 
execution relative to the enclosing such group whose<DO 
statement > bears <label>. The fofm REPEAT controls execution 
relative to the innermost such group. Execution is caused 

to abandon the current cycle of the DO. . .END group, If the 
conditions of the opening <DO statement > are still satisfied 
the next cycle of execution begins normally . 

O 

5. Code blocks (procedures, functions, etc.) may appear i^ithin 
DO. . .END groups. However, EXIT, REPEAT, and GO TO statements 
may not be used to cause execution to branch into or out of 
such' code blocks. 
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8. REAL TIME CONTROL 


0 


W 

o 

HAL/S contains a comprehensive facility for creating 
a multi-processing job structure in a real time programming 
environment . At run time a -Real Time Executive (RTE) con- 
trols the i^xecution of processes held in a process queue. 
HAL/S contains statements which schedule processes (enter 
them in the process queue ) , terminate them (remove them from 
the process queue ) , and otherwise direct the RTE in its 
controlling function, HAL/S also contains means whereby the 
use of data by more than one process at a time is managed in 
a safe, protected manner at specific, localized points within 
the processes. 








8. 1 Real Time Processes and the RTE. 


In HAL/S/ a program or task may be scheduled as 
a process and placed in the process queue. Although the 
process created is given the same name as the program or task, 
it is important to distinguish the static jffH^GRAM or TASK 
block -from the dynamic program or task pr^t^Js^. created. Two 
processes are actually involved in the creafti<,^ of a process: 
the scheduling process , or "father"; and the scheduled process, 
or "son" .1 


A process fs said to be either "dependent" or "independ- 
ent" , "as designated when created. A program or task process 
is "dependent" if it is absolutely dependent for its existence 
upon the existence of its father. If a orogram process is 
"independent" its existence is independent of that 
of all other processes. If a task process is "independent" 
its existence is generally independent of that of all other 
processes with an important exception: the program process in 

whose static PROGRAM block the static TASK block of the task 
process is defined. 

Each process in the RTE's process queue is at any 
instant in one of a number of states. For the purposes Of 
this Section, the following states are defined:^ 


• "active" - a process is said to be in the active 

state if it is actually in exeGution. Depending 
on the implementation it m^y be possible for 
several processes to be in execution simultaneously. 

• "wait" - a process is said to be in the wait state if 

it is ready for execution but the RTE has decided 
on a priority basis that its execution should be 
delayed or suspended. 


f "ready" - a process is said to be in the ready state 

if it is in either the active or the weit states 

• "stall" - a process is said to be in the stall state 

if some as yet unsatisfied condition prevents it 

from being in the ready state. 

The occurrence of a procTess being brought into the active 
state for the first time is called its "initiation". 



except of course for the first or "primal" process which 
must be created by the RTE itself. 


these states are not necessarily defiftitive of those actually 
existing in any particular implementation of the RTE. 


o 




O 


>-:0 


Execution of a CLOSE or RETURN statement by an active 
process causes the following sequence of events; 

1. CANCEL commands are issued for all DEPENDENT process 
still on the process queue. (See Section 8.4) 

2. The processs enters a stall state until all DEPENDENT 
processes have finished. 

3. The current cycle is deeme^d finished. Control reverts 
to the RTE which may or may not remove the process from the 
process queue . 

O 


8.2 Timing Considerations. 

In the HAL/S system, the RTE contains a clock measuring 
elapsed time ("RTE-clock" time) , Time is measured in "machine 
units" (MU) whose correspondence with physical time is imple- 
mentation dependent, HAL/S contains several instances of timing 
expressions which in effect make reference to the RTE-cloCk. 

Simultaneous occurrences produce implement at'lsa'n dependent 
results. 



|7 





8.3 The SCHEDULE Statement. - 

Q 

Processes are scheduled (placed in the process (jueue) 
by means of the SCHEDULE statement. The statement has many 
vauriant forms and offers the following features: 

• A process may be scheduled so that the RTE immediately 
i places it in a ready state, or so that the RTE places 

it in a stall state pending some condition being satis 
fied. 

• A process may be designated dependent or independent. 

• The cyclic executioh of a process may be specified. 

• Conditions of f uture ^ jf emoval of a process from the 
process queue may be| specified. 

SYNTAX: 


SCHEDULE lUttmtnt 





after V— I arithsjip 



EVERY iyA 

•xamptei ^ ^ L_> — 

SCHEDULE IOTA PRIORITY |6); 

SCHEDULE DELTA PRIORITY (P 2| DEPENDENT, REPEAT EVERy 15.9; 







SEMANTIC, RULES; . 

1. SCHEDULE <la^el> schedules a prograun or task with the 
name <label>, placing a new process with name <label> in 
the process queue. A run time error results if a 
process of that name already exists in the process queue. 
Unless otherwise specified the RTE puts the new process 
in the ready state immediately after execution of the 
SCHEDULE statement. 

2. The phrase IN <arith exp» is used to cause the process 
to be put in the stall state for a fixed RTE-clock dura- 
tion. <arith exp> is any unarrayed integer or scalar 
expression evaluated once at the time of execution of the 
SCHEDULE statement. If the value is not greater than 
zero then the process is put immediately in the ready 
state. 

3 . The phrase AT <arith exp> is used to cause the process 
to be put in the stall state until a fixed RTE-clock 
time. <arith ekp> is any unarrayed integer or scalar 
expression evaluated once at the time of execution of 
the SCHEDULE statement. If the value^ is not greater than 

- 0 the current RTE-clock time and th^^^ l^^ option 

is not specified, then the process is put immediately 
in the ready state. If the value is less than the current 
RTE time and the REPEAT EVERY option was specified, then 
phased scheduling takes place. The process is put in a 
stall state until a future time computed by the expression 
CT + RE - ( (CT-AT) MOD RE), where CT ■ current time, RE = RE- 
PEAT EVERY cycle time, and AT = originally specified AT tima. 

4. The phrase ON <event exp> is used to cause the process 
to be put in the stall state until some event condition ' 
is satisfied. Starting from the time of execution of 
the SCHEDULE statement, the <ev^nt exp> is evaluated at 
each "event change point"^ until its value becomes TRUE. 

At that time the process is placed in the ready state. ® 

If the value of <event exp> is TRUE upon execution of the 
SCHEDULE statement, then the process is immediately “ 

put in the ready state. 


^ the meaning of an "event change point" is defined in 
bisection 8. 8 . ^ 
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5. The initiation priority is set by, means of the phrase 
PRIORITY (<arith exp>) where <arith exp> is an unarrayed 
integer or scalar expression which is evaluated once on 
execution of the SCHEDULE statement. Scalar values^are 
rounded to the nearest integral value. Its value must^::;^ 
be consistent with the priority numbering scheme set up 
for any implementation, otherwise a run time error results. 

A priority value must be present in the SCHEDULE statement. 
Interpretation of priority is implementation dependent. 

6. When the keyword DEPENDENT is specified, the process created 
by the SCHEDULE statement is dependent upon the continued 
existence of the scheduling process. Note, however, that 

a TASK process is always ultimately dependent upon the en- 
closing PROGRAM process. Thus when scheduling a TASK from 
the PROGRAM level of nesting, the keyword DEPENDENT is re- 
dundant and need not be specified. 

O 

7. The REPEAT phrase of the SCHEDULE statement is used to 
specify a process which is to be executed cyclically by 
the RTE until some cancellation criterion is met. If the 
REPEAT phrase is not qualified, -^en cycles cf execution 
follow each other with no intervening time delay. To 
cause execution of consecutive cycles to be separated by 
a fixed intervening RTE-clock time delay, the qualifier 
i^TER <arith exp> is used. <arith exp> is an unarrayed 
integer, scalar, or FIXED expression evaluated once at the 
time of execution of the SCHEDULE statement. If the value 
is not greater than zero then no time delay results. To 
cause the beginning of successive cycles of execution to 

be separated by a fixed RTE-clock time delay, the qualifier 
EVERY <arith exp> is Used. <arith exp> is an unarrayed 
integer or scalar expression evaluated once at the time 
of execution of the SCHEDULE statement. If the value is 
such as to cause a cycle to try to start execution before 
the previous cycle has finished execution, then a run- 
time error results. 


8. Between the successive cycles of executicS' of a cyclic 
process, the process is put in a stall state and retains 
the machine resources the RTE reserved for it. It is 
not temporarily removed from the process queue. 


5. 


The WHILE and UNTIL phrases provide a cancellation cri- 
terion for a cyclic process. Before the cyclic process is 
initiated , they also provide a means of removal of the 
process from the "process <|ueue. In this latter capacity , 
they also apply to non-cyclic processes. 
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• The UNTIL <arith exp> phrase specifies a cancellation 
criterion based on RTE-clock time. <arith exp> is an 
unarrayed integer, scalar or fixed expression evaluated 
once at the time of execution of the SCHEDULE statement. 
For any process, cyclic or non-cyclic, the following is 
trueP If the value of <arith exp> is not greater than 
the current RTE-clock time, then the process is^'never 
entered in the process queue. Otherwise 'a CANCEL command 
is issued if the RTE-clock equals <arith exp> while the 
process is still on the process queue (see Section 8.4 ). 



151 


11. The WHILE <event exp> phrase specifies a cancellation 

criterion based on an event condition. For any process, 
cyclic or non-cyclic, the following is true. If the 
value of <event exp> is FALSE at the time of execution 
of the SCHEDULE statement, then the process is never 
placed in the process queue. If not, then ^J^vent exp> 
is evaluated at every "event change point" until its 
value ’becomes FALSE. At this time a CANCEL command is 
issued if the process is still on the process queue (See 
Section 8.4). 


12. The UNTIL s:jSvent exp> phrase als^q specifies a cancella- 
tion criterion based on an event”" condition. However, it 
differs fundamentally from, the WHILE < event exp> phrase 
in that it always allows at least one cycle of a cyclic 
process to be executed. Consistent with this, the phrase 
has no meaning at^ therefore no =sf f ect in the ca.se of a . 
rion-cyclic prope^"!^. For a cyclic process, the value of 
the < event exp> is evaluated at every "event change point "| 
from the time of execution of the SCHEDULE statement. ‘ I 151 


If <event exp> becomes TRUE prior to the end of the first 
cycle, a CANCEL command is issued at the end of the first 
cycle. Otherwise if < event exp> becomes TRUE while the 
process is still on the process, queue, a CANCEL command 
is issued at that time. (see Section 8.4 ). 
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8.4 The CANCEL Statement. 

Cancellation of a process may be the result of the 
enforcement of a cancellation criterion in the SCHEDULE 
statement which created the process , or alternatively ^^mey 
be the result of executing a CANCEL statement. ^ 

SYNTAX: 


CANCEL stitMTWfit 


' baue ^ 
. statannant . 



axampla: 


FINISHING: CANCEL ETA. NU; 


SEMANTIC RULES: 

1- CANCEL <label> causes cancellation of the process <label>. 

A run time error results if the process queue contains no 
process with that name.* The CANCEL statement can be used 
to cancel any number of processes simultaneously. 

2. If the CANCEL statement has no <label>, cancellation 

of the process executing the CANCEL statement is implied. 


the default action taken by the Error Recovery Executive 
for this and other similar errorsomay be to ignore the 
error. 








3> If at the time of execution of the CANCEL statement, a 
process to be cancelled has not^ yet been initiated, then 
the process is merely removed from the process queue. 

This applies to both cyclic and non-cyclic processes. 

4. If at the time of execution of the CANCEL statement a 

process to be cancelled has already been initiated, then 
the following ensues: If the process is non-cyclic 

and it has already been initiated, the CANCEL statement 
has no effect; if the process is cyclic, then the 
process 'is removed from the process queue at the end of the 
current cycle of execxition. p 
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8.5 The TERMINATE Statement. 

& 

* . 

The termination of a process results in the immediate 
cessation of execution of the process, TERMINATE 's of depen 
dents, and removal from the process queue. The TERMINATE 
statement is used to direct the RTE to terminate specified 
processes or the process issuing the TERMINATE* 


TERMINATE (tautHMt 


f basic N 
, stattmant . 



txampla: 


STOP; TERMINATE ALPHA. BETA; 


SEMANTIC RULES: 

1. TERMINATE <label> causes termination of the process 
<label>. A run time error results if a process of that 

c?- name is not in the process queue, or if it is not a 
dependent son of toe process currently executing the 
TERMINATE statement. The TERMINATE statement can be used 
to terminate any number of processes simultaneously. 

2. If the TERMINATE Statement has no <label>, termination of 
the process currently executing the TERMINATE statement 

.3 is implied. ^ 


^ subject of course to implementation dependent safety 
constraints . 





8.6 The WAIT StatemenL 

Tbe WAIT statement allows the user to cause the RTE 

to place a process in the stall state until some condition 
IS satisfied. 


SYNTAX: 



1. The WAIT <arith exp> version specifies that the process 
executing the WAIT statement is to be placed in the stall 
state for an RTE-clock duration fixed by the value of 
the expression. <arith exp> is an unarrayed-^integer , 
scalar or fixed expression evaluated once at the time of 
execution of the WAIT statement. If the valu^ is not 
greater than zero, the WAIT statement has no bffect. 

2. The WAIT UNTIL <arith exp> version specifies that the 
process executing the WAIT statement is to be placed in 
the stall state until an RTE-clock time 'fixed by the 
value of the expression. <arith exp> is an unarrayed 
integer, scalar or fixed expression evaluated once cat the 
time of execution of the WAIT statement. If the value 

is not greater than the current RTE-clock time, the WAIT 
statement has no effect. 



(? 


The WAIT FOR DEPENDENT version specifies that the process 
executing the WAIT statement is to be placed in the stall 
state until all its dependent sons have terminated. If 
there ate no such processes r the WAIT statement has no 
effect. 

The WAIT FOR <event exp> version specifies that the pro- 
cess executing the WAIT statement is to be placed in the 
stall state until an event condition is satisfied. Start- 
ing from the time of execution of the WAIT statement, 
the <event exp> is evaluated at every "event change point" 
until its value becomes TRUE , whereupon the process is 
returned to the READY state. If the value of <event exp> 
is TRUE upon execution of the WAIT statement, then the 
statement has no effect. v> 


0 







ij 
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S. 7 Hie uraATC PRIOR ITY Statement. 

tnie SCHEDULE statement which creates a process can 
also specify the priority of its initiation. At any time 
between the scheduling and the termination of the process, 
that priority may be changed by means of the UPDATE PRIORITY 
statement. 

SYNTAX: 

■I 

. "S' 

H . . 



SEMANTIC RULES: 

1. UPDATE PRIORITY <lab^X> is used to change the priority 
of the process with name <label>. The new priority is 
given by the value of <arit|i exp>. <arith exp> is an 
unarray^d integer or scalar expression whose value must 
be consistent with the priority numbering scheme set up 
for any implementation, otherwise a run time error results 
Scalar values are rounded to the nearest integral value. 

A run time error results if there is no process with name 
<label> in the process queue. 

2. UPDATE PRIORITY with no <label> specification is used to 
change the priority of the process executing the UPDATE 
PRIORITY statement. <arith exp> has the same meaning as 
before. 
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8.8 Event Control 




Although a formal specification of events and event 
expressions has already been given in Sections 4 and 6.3, the 
Specification has not yet made their purpose clear in the con- 
text of real time programming. Superficially event variables 
are closely akin to boolean variables in that they are binary- 
valued. Conceptually the two forms of HAL/S events (latched 
and unlatched) may be thought of as the software counterparts 
of hardware discretes and timing lines, respectively. 


• a latched event may be thought of as a boolean system 
state which may be SET or RESET by appropriate actions , 
or moiifentarily changed for signalling purposes. 


• an unlatched event may be thought of as the software 
counterpart of a taming line which is used purely for 
signalling - it: is noamaally P^SE but becomes -TRUE 
momentarily when a signal action is executed. 

o 

This analogy is ho accident, since event varieible;s can actually 
fom the interface between HAL/S software and such hardware 
control signals. The design and operation of this interface ' 
is imp lemen t at ion dependent . 


u 


^ At any instant of time the RTS may be viewed as having a 
knowledge of all existing events. Whenever the value of an 
event changes, the RTE senses this so-called "event change 
point”, and may in response perform the evaluation of certain 
<event exp>s. Depending on the results of the evaluations, the 
states of , one or more processes may be changed. This response 
of the RTS to changes in event variables is termed an "event 
action" . The Value of an event variable can change in response 
tp the enV^ironment external to the HAL/S software; depending 
upon the type of event (see SEMANTIC RULES) , a SET, RESET, or 
SIGNAL st«itement may also be. dsed to alter the state of an event 
variable. The only event change actions possible are to ready 
or cancel .one br more process. 


SET,SIGNAL and RESET tutamantt 


/ basic \ 
statement ) 


rC 



label 


SET 




• {^ SIGNAL~^ -» 


RESET 


event yar 


example: 

SIGNAL iota; 



r 






GENERAL SEMANTIC RULE: 

a 


1. <event var> denotes any unarrayed event variable, subscripted 
or unsiibscripted. 

SEMANTIC RULES (latched <event var>sj : 

© 

1. SET changes the value of^^the <event var> to TRUE and initiates 
all event actions depending upon the TRUE state of this event. 
No action is taken if the <event var> is already TRUE. 

2. RESET changes the value of the <event var> to I^MjSE and i|ii- 
tiates all event actions depending upon the FALSE state Cf 

, this event. No action is taken if the <event var>ii is already 
FALSE. 

3. , SIGNAL does not change the state of a latched event. 


4. If a latched event is TRUE, SIGNAL initiates all event actions 
depending upon the FALSE state of this event. 


5. If a latched event is FALSE, SIGNAL initiates all event 1 

actions, depending upon the TRUE state of this event, I 

SEMANTIC RULES (unlatched < event var>s) : // 1 


1. SET and RESET are illegal for unlatched <event var>s. 

O ' 

- ' >) 

2. When used in a <bit expression> , an mlatched eyent variabl^^^^ 

( • is equivalent to a literal "FALSE”. 

3. SIGNAL initiates all event actions depending upon the TRUE 
state of this event. Note that when an event expression 
depends upon a logical product of multiple <eveht Yar>s, 
at most one such <event var> can be unlatched if the evehf 
action is ever to be taken. 



SUMMARY 


RESET 


SIGNAL 


unlatched event 


’ illegal 


illegal 


Take all eveht 
actions depending 
on TRUE state of 
<event var> 


latched 

event 


old 

value 

is 

FALSE 


1. Set event state 
to TRUE 

2. Take all event 
actions Qepending 
on TRUE state of 

<event var> 


no action 


.Take all event 
actions depending 
on TRUE state of 
<event var> 


latched 

event 


old 

value" 


no action 


1. Set event 
state to FALSE 

2. Take all 
event actions 
depending on 
FALSE state of 
<event var> 


Take all event 
actions depending 
on FALSE State of 
<event var> 
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8.9 Process '--wents. 


\ 
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Every program or- task biloc<f has associated with it 
a "process-event" of the same name. This process-event behaves 
in every way like a latched event exc^t that it may not 
appear in SET, RESET oi^SIGNAL statements. Its purpose is 
to indicate the existence of its associated program or task 
process. If a process of the same name as the process-event 
exists in the process queue, the value of' the process-event 
is TRUE, otherwise it is FALSE. 
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8. 10 Data Sharing and the U PDATE Block. 

^The UPDATE block provides a controlled environment 
f^“the use of data variables which are shared /by two or more 
processes. If controlled sharing of certain variadsles is 
desired, « they must possess the LCX!K(N) attribute, where N 
indicates the "lock group" Of the variable (see Section 4.5) . 
LOCKed variables may only be used inside UPDATE blocks. A 
LOCKed variable appearing inside an UPDATE block is said to 
be "changed" within the block if it appears in one or more 
statements which may chamge its value (t&e left-hand side 
of an assignment for example) . It is said to be "accessed" 
if it only appears in contexts other than the aJaove.f 

A formal specification of the UPDATE block appears in 
Section 3,4. The manner of operation of an UPDATE block is 
implementation dependent, but is such as to provide certain 
safety measures. 


OPERATIONAL RULES: O 

O , 

1. If two processes both require variables from the same 
lock group to be changed, then the first process entering 
its UPDATE block must complete execution bt the biock before 
the other process can enter its own UPDATE block. The 
second process is placed in a stall ^state for the duration. 

2. If bnO process entering an UPDATE block requires a 
variable (s) with the attribute LO&K(*) to be changed, 
then the situation is equivalent to one in which the 
process requires use of h va.riablS from every lock group. 

3. If only one of the processes requires a variable of a 
lock group to be changed, the other merely requiring it 

to be accessed, then depending on the implementation, , 

either Rule 1 or 2 holds, or some overiap in execution 
of the two processes ' UPDATE blocks is allowed. The 
nature of such overlap must be such as to provide 
exclusive use of the lock group by the process requiring 
its change between the point where the variable is changed 
and the close of the UPDATE block. 

4. If both processes only require a variable of the same lock 
group accessed, then execution of the two processes ' UPDATE 
block may be allowed to overlap depending upon implementation . 

5 . If there are several simultaneous conflicts '^in using 

shared variables because of the participation of more 
than two processes, or more than one lock group , then 
the most restrictive of Rules 1 through 4 required is 
applied to resolve the conflicts. ' 









9. ERROR RECOVERY^’AND CONTROL 


(( 


References to so-called 'run time er£OES^^ have been 
made elsewhere in this Specification* Such errors arise at 
executtion time through the occurrence of abnormal hardware 
or system software conditions. Each HAL/S implementation 
possesses a unique collection of such errors. The errors 
in the collection are said ,to be "system-defined” . In any 
implementation ' every possible system-defined error is assigned 
a unique "error code". In addition, a number of otiher legal 
error codes not asiigned tb system-defined errors may exist. 
These can be used by the HAL programmer to create "user- 
defined" errors. All run time errors, both system- and user- 
defined, are classified into "error groups". The error code 
for an error consists of two positive integer numbers, the 
first representing the error group to which it belongs, and 
the second uniquely identifying it within its group. The 
method of classification is implementation dependent. 


|Vt run time an Error Recovery Executive (ERE) senses 
errors, both system-defined and user-defined, and determines 
what course of action to take. For every error group, a 
standard system recovery action "is '%efined which the ERE will 
take unless error recovery has been otherwise directed by the 
user. Depending on the error and the implementation, the 
standard system recovery action may be to terminate execution 
abnormally, to execute a fix-up routine and continue, or to 
ignore'lthe error. 

In a real time programming context, every process in 
the process queue has a separate, independent "error environ-^' 
4nen.^^which is continuous from the time of initiation of 
the process to the time of its termination. At any instant 
of time the "error environment" of a<jprocess is the totality 
of error recovery acti'bns in force at that^ time for all 
possible errors. A]t .the time of initiatibh of the f, 
process, the stahdjird system recovery action is in fbrce for 
all errors. 

. ■ ■ " 'O' . ■ ■ ' ' 

HAL/S possesses two error recovery and control state- 
ments . The ON ERROR statement is used to modify the error 
environment of a process at any time during its life. The 
SEND ERROR statement is used for the two-fold purpose of 
creating user-defined error occurrences, and simulating system- 
defined error occurrences. 


9-1 


o 


C/ 


Cj 


9. 1 The ON ERROR Statement 

o 
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TSie error environment upon> entry to a code bloclc (other 
than PROGRAM or TASK) is unchanged from that of the previous 
statement executed. If a code block changes the error environ- 
ment, the entry environment is resto 7 .*ed upon exit from the code 
block. o 


i 0 The ON ERROR statement is used to. change the error 
environment prevailing at the time of its execution. It^ 
can change the error^ recovery action for one selected ^ 
error code, foplpne ‘selected error group, or for all 
gfolips simultatt^usly. There are two basic forms of 
the statement : ON ERROR and OFF ERROR. 

^ ^ If an ON ERROR with a given specif icd,tion is executed in 
a particular code block, then the modified s*ecovery action 
remains in force dntil one of three things happen: 


• the modification is superseded by execution of 

a ?secon&‘ 'b?J ERROR with, the same error specification* 

r.— 

• the modification is removed by execution of an 
OFF ERROR with the same error specification, the 
recovery action thereupon reverting to that in 
force on entry into the code block. 

• the modification is automatically removed by exit 
from the code block . 
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SEMANTIC RULES 


<= u 

1. The ON ERROR Statement consists of two parts: a 

specification of an error action to be taken by the 
ERE, preceded by an <error speo specifying, the" 
error number, error group or groups to which the 

0 action is to apply. 

2. There are three forms of <error speo, for specifying „ 
either all error groups, or a selected error group, 

or a selected error code. 

• The form of <error speo without subscript is 
used to specify all error groups. 

• The subscript construct <number> with optional 
following colon is used to specify a selected 
<error group>. The value of <nvunber> is restricted 
to the set of error group numbers defined for a 
particular implementation. 

• The subscript construct <nprf5er>: <number> is used 
to specify a selected error code. The leftmost 
<number> designates the error group ntimber; the 
rightmost <number> the selected error number within 
the group. Values are restricted to the set of 

error codes defined for a particular implementation. 

a 

3. The form ON ERROR .... specifies the modification of 

the error recovery actions for the given <error spec>. 
OEF ERROR ... . specifies the removal of a modification 
previously activated in the same name scope for the 
same <errornspec> . If no such modification exists,., 
the OFF ERROR is effectively a no-operation. ’ 

4. The presence of the IGNORE clause specifies that in the 
event of occurrence of a specified error, the ERE is 

to take no action other than allow execution to proceed 
as if the error had not occured. The IGNORE action may 
not be permitted for certain errors. 

5. The presence of the SYSTEM clause specifies that in the 
event of the occurrence of a> specified error, the ERE 
is to take the standard system recovery action. 

.-J 
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6. The form 0N„ EREOR ... <statement> specifies that 

<statement> is to be executed on the occurrence of a 
specified error. <statement> may optionally be 
labelled. However, such labels may only be referenced 
by EXIT or REPEAT Statements within the (compdiind) 
<statement> thus labelled. After execution of ’fstatement>, 
execution normally restarts from the executable statement 
following the 01^ ERROR statement. Execution of <statement> 
itself may of course modify this. 

li It is important to note that the fotrm ON ERROR .... 

<statement> is itself a <statement> while other forms 

of ON ERROR are <basic statement>s. The foria ON ERROR ... 

<statement> may therefore not, be the true part of an 

IF. . .T^JEN. . .ELSE Statement. ” 

8 . If an ON ERROR possesses a SYSTEM or IGNORE clause , 
it may also possess an additional SIGNAL, SET, or 
RESET clause. The purpose is to cause the value of 
an <event var> to be changed on the occurrence of a 
specified error. Its semantic rules are the same 
as those described for the corresponding SIGNAL, SET 
and RESET statements in Section 8.8. Note that if 
<event var> contains a subscript expression, then that 
expression will be evaluated at the time of execution 
of the ON ERROR statement, not on the occurrence of the 
error. ' / 



PRECEDENCE RULE: 

1. An ON ERROR executed within a code block always \):otally 
®^]^®tsede,5 cn ON ERROR executed before entering the code 
block. !,\ 1 


Within a code block the action specified by an ON ERROR 
is only superseded by another if the two < error speOs 
'^are of identical form. Similarly an OFF ERROR nullifies 
the effect of a previous ON ERROR only if the two <error 
spec>s are of identical form. However, dif ferent forms 
of <error spec> may involve the same error group or error 
code. It is logically possible for up to three ON ERRORS, 
each with a different form of <error speO as deseribed 
in Rule 2 above, to be active simultaneously and involve 
the same error code . The ON ERROR precedence order for 
determining the recovery action in the ev«»nt of an error^ 
occurrence is as follows; 



Error 

Specif icat ion 


<error spec> 
subscript 
construct 


// 


' Precedence 



,n 

lAST 

all groups 

- 

1 

selected group 

/^number> : ) 

2 


1 <n\imber> / 


selected error 

<number> ; <niunber> 

3 

code 




- 1 

-■ FIRST ^ 





9.2 The SEND ERROR Statement. 


The SEND ERROR statement is used to announce a selected 
error condition to the ERE. If the error selected is •system- 
defined' then in effect that error is being simulated. 

SYNTAX; 




SEMANTIC RULES; 

1. <number> : <number> is a subscript construct consisting 
of two unsigned integer literals. The leftmost <number> 
designates the error group, f to which the selected error 
condition belongs. The rightmost nximber denotes the 
error number within the designated group. Values are 
restricted to the set of error codes defined for a 
particular implementation. If the error code corresponds 
to a system-defined error, then that error is simulated 
by the ERE. Simulation of certain system-def ined errors 
may not be permitted, 

' I 

2. The action taken by the ERE after’' announcement of the 
selected error condition is dictated^^^by the error 
environment prevailing at the time of execution of 
the SEND ERROR statement. 
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10. INPUT/OUTPUT STATEMENTS 


The HAL/S language provides for %'i^o forms of I/O: 
sequential I/O with conversion to and ftom an external 
character string representation > and random-access record- 
oriented I/O./' 

. All HAL/S I/O is directed to one of a number of 
input/output "channels”. These channels are the means used 
to interface HAL/S software with external devices in a run 
time environment. In any implementation each channel is 
assigned a unic[ue unsigned integer identification number. ^ 

The input/output statements described in this section 
are intentionally general-purpose. They provide a basic 
support facility for applications programming on the Shuttle 
project. Specialized hardware-oriented I/O commands may 
be created via features of the HAL/S Systems Language, 
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10. 1 Sequential I/O Statements. | 

I All sequential I/O in HAL/S is to or from character- 

/ oriented files. HAL/S pictures these files as consisting of 
lines of character da ta similar to a series of printed lines 
or punched cards. A4 '’’’unpaged" file simply c<>nsists of an 
unbroken series of such lines. In a "paged" file the lines 
are blocJted into pages, each a fixed, implementation depend- 
ent munber of lines in length. The choice of paged or 
unpaged file organization for each sequential I/O channel is 
specified in an implementation dependent manner. 

HAL/S pictures the physical device as moving across 
the file a read or write "device mechanism" which actually 
performs the data transfer . The device mechanism has at ^ 
every instant a definite column and line position on the V)ile. 
The action of transmitting one character to or from the file 
is followed by the positioning of the device mechanism to 
the next column on the same line. When the end of the line 
is reached the device mechanism moves on to the first 
(leftmost) column of the next line. 

The HAL/S sequential I/O statements are the READ, 
RE.ADALL, and WRITE statements. Within these statements I/O 
control functions can be used to cause explicit positioning 
of the device mechanism on the file. 


II 

I 


;! 
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10.1^1 The Ri^AV and REAVALL Statement6 

0 

The sequential input of data is accomplished in HAL/S 
by employing either a^AD or a READALL statement.^ ;?he choice 
depends upon, the format of “the character input and^ the conver- 
sions (if any) which are to be performed’?^' 

I 

A READALL statement is used whs-reveiQarbitrary character 
string images are to be ' input wirthout conversionj,^ otherwise READ 
,is used. o « ■ 

^ ft <format list>s may be used with READ statements when data 
is not in a standard external format, e.g. if two numbers are 
Ideated, in consecutive columns withbut separation. 


basic \ 

REAP AND READALL STATEMENTS 

f 

statement / 

\ 


arlth exp 


READALL 



van able 


i/o 

control 

format 

list 


example: PEAD(5) VAR,(y,Z)iN 


DELTA 


GENERAL SEMANTIC RULES: )) 

1. <arith exp> is an unarrayed scalar or integer arithmetic 
expression. The value is treated as an integer: scalar 

“values are rounded to the nearest sLnteger prior to use. 
The value must represent a legal I/O channel number. 

2. <i/o control > is any legal I/O control function used to 
position the device mech^b^sm explicitly. 
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Unless overridden Iby Explicit <i/o cQntr5Jl> or < format list>» 
the device mechanism is automatically moved to the leftmost 
column position and advanced to the next line prior to reading 
the first <^variable>. A SKIP, LINE, or PAGE before the first 
<variable> overrides the automatic line advancement. A, 

TAE or COLUMN overrides the automatic column positioning. 

% * U o 

An unexpected end of file reached during the reading op 
data from tJ^ input file causes a runtime error. 

<variable>*s are read in order. Each <variable>'s subscript 
is evaluated just prior to its input. » 


SEMANTIC RULES (READALL Version) ; 

1. <variable> may be any character or structure variable 
/?^n an assignment context. This specifically excludes 

input parameters of functions and procedures, if^it 
is of structure type, all the terminals of the template 
it references must be of character type. |In this case,, 
also no nested structure template references are allowed. 

2. If <variable>^ is an array or structure each element 
thereof is filled sequentially in its "natural sequence". 

3. Data is read ftom the input file character by character 
from left to right, each <variable> element being filled 
in turn. Pilling of an element is completed either when 
the end' of a line on the file is reached, or when the 
element has reached its declared maximum length, which- 
ever happens sooner, 

4. <format list> ipay not be used with READALL,. 


SEMANTIC RdIes (READ Version) } 

1. <variable> is any variable which may be used in an assignment 
context. This specifically excludes input parameters of 
functions and procedures « 

2. If <variable> is a vector or matrix, or ai^jrray or structure, 

each element thereof is filled sequentially^ in its "natural 
sequence " . ■ | 

3. When reading data speoified in a format list the device 
mechanism is positioned by the format list ; All the 
characters in the field determined by the format are 
transmitted and converted to the internal HAL/S data type. 

If the width of the speMfied “field is greater than the 
number of” characters regaining on the line, an implementa- 
tion dependent mechaniMip is invoked. 
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4, 


5., 


6 , 


7. 


In the absence of a <forroat Iist>» the device mechanisni 
(subject to <i/o control>) scans the input file ieft to right, ^ 
frolm line to line, looking fields of contiguous characters^ 
separated by commas, semicolons or blanks. Each field found 
is in turn transmitted and converted from its standard exter- 
nal format to an appropriate HAL/S data value. Fields may 
hot cross line boundaries except when reading character 
strings . 

When not under control of a <format list>, a semicolon field 
separator encountered during a normal sequential scan to 
fill a variable element terminates the READ statement as 
follows s 


I 145 


145 




• The current variable element is left unchanged; 

•All remainiT^ <variable>s In the statement are unchanged) 


•All remaining control functions in the statement are 
ignored. 

<i/o control> functions can force the device mechanism over 
the semicolon without causing early termination. 

When not under control of a ^format list>, a null field is 
transmitted whenever a comma or a semicolon is detected when 
data is expected. This occurs when a comma or semicolon ih; 

• presided by a comma or semicolon; 

• preceded by oSie or more blanks following the last comma 

or semicolon. ° 

When under control of a <format*^list>, a null field is 
transmitted and an error sent whenever the field being 
read is entirely bisnk , 

A null field causes the corresponding variable element to 
remain unchanged following transmission^. 

For READ>^tatements , fields must cither be read using 
<forraat or else they must appear in a standard 
external format. A list of standard external formats is 
given in Appendix E. A type mismatch cause'^ a runtime error . 


145 


111 


145 


145 
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10 .1. Z Th& mm statemnt 

The sequential output of data is accomplished in HAL/S 
by employing the WRITE statement. 

<format list>s may be used to output data in non-standard 



SEMANTIC RULES; 

1. <arith exp> is an unarrayed scalar or integer arithmetic 
expression . The value is treated as an integer; scalar 
values are rounded to the nearest integer prior to use. 

The value must represent a legal I/O channel number. 

2. <i/o control> is any legal I/O control function used to 
position the device mechanism explicitly. 

3. There are no semantic restrictions on <expression> . 

4. If <expression> is of vector or matrix type, or is an- array 
or structure, then each element thereof is transmitted se- 
quentially in its "natural sequence". 
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Unless overridden by explicit <i/o control> oi^ a 
< format list>, the device mec^»anism i% automatically 
moved to the leftmost column position and advanced to 
the next line prior to transmitting the first <expression> . 
A SKIP, LINE, or PAGE <i/o control> before the first 
<expression> overrides the automatic line ad^ancoment. 

A TAB or COLUMN <i/o control> overrides' the “automatic 
column positioning. » 


,^Each <expression> in turn is converted to its standard 
external format before being transmitted to the output 
file. A list of standard external formats is givfn in 
Appendix E. 


<format list>s may specify additional <expression>s to be 
transmitted in non-standard formats. 


Example! 


Output INTEGERS K1 and K2+K3 in columns 1-^S and 6-10, 


respectively! 


WRITE (6) (Kl,= K2+K3) IN *215 'i 


When not under control of a <format liS'5i> , the device 
mechanism is moved to the right by an implementation de- 
pendent number of columns between the transmission of two 
consecutive elements. If a TAB cgj;;«GOLUMN <i/o control> 

Y separates two consecutive <i'expression>s then this over- 
rides the automatic movement between trahsmission of the 
last element o%the first <expression> and the first element 
of the second <"^)>cpression> * ^ ^ 


9. When a line has been filled to the point where the next 

c'Snverted output field will not fit in the remaining columns, 
a wrap-around condition occurs. The actions taken in such a 
case are implementation dependent. 
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I0.I.3 I/O Contfiot FuimtionA. 


An I/O control function is introduced into a READ, 
READALL, or WRITE statement tc> cause explicit movement of the 
device /mechanism. Note that the ijiterpretation of each I/O 
control function differs depending upon whether the file is 
paged or unpaged. 


SYNTAX: 


i/o control funenon 


i/ocontrot 



arithtxp 


Mampw : 


COLUMN (i-l-Z) 


SEMANTIC RULES: 

1. <arith exp> is ah unarrayed scalalr or integer arithmetic 

expression specifying a value to the” control function. 
The value is treated as an integer: scalar values a^e 

rounded to the nearest ir^teger prior to use. In the% 
following rules,, let the value of <arith exp> be denoted 
by K. ' y/ 

2. TAB (K) specifies ^relative movement of the device mech- 
anism across the current line by K character positions 
(columns). Motion is to the right (increasing column 
index) if K is posijiiye, to the left if K is negative. 

7 Positioning to negative or zero column index values, or 
to a positive index gtbater than an implementation depen 
dent maximum causes a tun time error. 
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3. COLUMN (K) specifies absolute movement of the device 
mechanism to column K of the current line. Values of 

K may range from 1 to an implementation dependent maxi*' 
mum value. Column indices outside the legitimate range 
cause run time errors. 

4. SKIP (K) specifies line movement relative to the current 
line of the file. A positive value of K will cause for- 
ward movement. Subject to implementation and hardware 
restrictions, backv/ard movement is ihdicated by a negative 
value pf K. Error conditions will be indicated if a 

skip cat^Sj^, movement past either e^d of the file# or 
movem«iit^n violation of any implementation restriction 
on the di!rec^on of the skip. 

A 0« 

5. LINE (K) specifies line movement to a specified line 
number , K . Two interpretations occur depending upon 
whether the. file is paged or unpaged. 

• Paged files - LINE (fC) advances the file uncondition- 

^ K may not be less than 1 or greater than the 

" implementation and hardware dependent number of lines 
per page, otherwise an error condition will be indi- 
cated. If K is not less than the current line number, 
the new print position is on the current page; if K 
is less than the current line number , the device 
mechanism is advanced to line K of the next page. 

II 

• Unpaged files - LINE (K) positions the device mechan- 
ism at some absolute line number in the file . On 
input K must be greater than 2ero, but not greater 
than the total number of lines in the file. On output, 
K must merely be greater than zero. In either case, 
values outside the indicated ranges cause run time 
errors. Depending on the implementation, values of 

K causing backwards movement may be illegal. % 

0 

6. PAGE (K) is only applicable to paged files and specifies 
page, movement relative to the current page. If^K is 
positive the movement is forward, towards the end of 
file. Depending upon t^je xmpl^ientation'^ negative page 
values may or may not l|e legalT^ The line value relative 
to the beginning ‘^pf thq page remains unchanged * 
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10.1.4 Fomr Uiti 


FORMA'B lists present '4 powerful way to perform I/O opera- 
tions with complete eicplicit control of allvsconversioh and lay 
out functions. ® 


format 

list 


FORMAT LISTS 


variabit 


axprauion 


variable 


expressiQn 


format character 
expression 


SEMANTIC RULES: 


examples: (A. B, C) IN 'F4:a' 1 1 INl_FORM 
D IN 'E15.6' 


1. A < format list> used with a READ may Only contain <variable>'s 
:.not <expression>'s. ^ 

2* <format character expression > is any character expression. 

A runtime check is made for legality. 


All variables in the < format character expression> are 
evaluated/before any 1/0 takes place involving the FORMAT 

I--' St. / „ 

I : '■ : ^ , ■ 

Each <expression> or <variable> is handled according to 
< format character expression>. If the <expression> or 
<variable> represents an aggregate of .elements, then each 
element is handled sequentially in it® naturual sequence. 

Example: DECLARE V VECTOR INITIAL (2 . 12 , 3.4, -7), 

F CHARACTER tae) INITIAL ( *F4 . 2, P5,lr F4. 1') 

then: 

WRITE (6) V IN F 

2.12bjrf3.477.0 


prc^duces : 


aotumn 







;i 


10.1.4.1 FORMAT Character Expressions . 

FORMAT character expressions aetermine h 9 W''items in FORMAT lists are 
■read or written. / ° 

SYNTAX: ^ 



SE!^ANTIC RULES: . 

1. <number>must be an unsigned, non-negative integer. 

2. Each item input or output is handled according to a pa^j^icular 
format item. If <number> precedes a format item, it is^hter- 
preted as if <^umber> copies of the format item had been writ- 
ten. If <number> precedes a parenthesized <format ^i character 
expression> , it is interpreted as if <number> ?;r:ppies of the 
<format character expression> had been .written. 

3. Each invocation of a READ or WRITE statement containing a 
<foi^at list> interprets the <format character expression> 
starting from the beginning. 

4. If the <format character expression> is exhausted and addi- 
tional items remain to be input or output, control is returned 
to the <format character expression> corresponding to the 
,l=ist closed parenthesis encountered. A preceding <nurober> is 
taken into account if present. If nO embedded <fomat char- 
acter string>Vs are present, conbrol reverts to the beginning. 

5. •/' is interpreted as-' , SKIP (1) ,CO&MN|l) , * . 

6 J) ' ■ \ ■ 
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6. 


Consecutive commas; are ignored . 


// 

0 


Examples 

DECLARE ARRAY (20), DIM VECTOR, ANIMAL CHARACTER (15) j 

WRITE(e) ('ANIMAL', ' LENGTH ',' W1 DTK ' , 'HEIGHT'^ 

IN 'A15, (Ald)'f = Y 

DO FOR TEMPORARY I = 1 TO 20? 

WRITE (6) (ANIMALj, DiMj) IN 'AlS, (PlO.l)'; 

END; 


produces : 

ANIMAL 

CENTIPEDE 

AA=IDVARK 

J i 

cotmn 15 


LENGTH 

3.1 

42.7 


ts 


WIDTH 

.3 

- 12.6 

.04 


HEIGHT 

,2 

1.2 

. 4 


o . 


^4, 


45 


(> 


c:? 





SEMANTIC RULES : 

1. At the beginning of the READ or WRITE statement and after 
processing an item, x format items, quote strings, and I/O 
control are processed until some other format item is reached. 

2 . The "’semantics of <1/0 ;control> were defined in Section 
ao.1.3. 

3. The following table briefly describes the formats. See 
individual items for fuller applications. 









10,1.4.3 1 FORMAT Item . I FORMAT items are used for INTEGER 

I/O. 


SYNTAX ; 


I rORMATITEM 



SEMANTIC RULES; 

1. <number> is the length of the field being transmitted. 
It is an unsigned positive integer, 

2. Implicit INTEGER/SCALAR conversion is allowed 


For READ Statements': 

1. A sign way preceed the input quantity. 

2. In input data, blanks before a sign or between a sign 
and the first digit are allowed. All other positions 
must contain digits between 0 and 9, otherwise a runtime 
error occurs. 

For WRITE Statements: > 

1. A sign is printed only if the number is negative. 

2. If the number pf print positions required tci represent 
the quantity is^less than number , leftmost positions 
are filled with blanks. If greater than number , a 
runtime error is sent and asterisks are printed in place 
of the quantity. 

Example: 

DECLAiE A INTEGER INITIAL (3) ; 

1 WRITE(6) (A, -2, A-2) IN '12'; 

produces : ■ " / 


lU-15 



10.1.4.4 F and E FORMATMteros . F ^FORMAT items are used for 
decimal quantities . E FORMAT items are used for decimal 
quantities written in scientific notation (i.e.. with exponents) 

0 . . o- 

SYNTAX: 


F and E FORMAT ItMiw 

Ham / 


fM iHimbtr 



examples: F9.2 
E14.3 


number 


SEMANTIC RULES: 

1, The first <number> is the width of the field being transmitted. 
The optional second <number> specifies the number of decimal 
pl^c^s to the right of the decimal point; if it is omitted, 

it is assumed to be zero. Each <number>,, if present, is an 
unsigned positive integer. 

2. Implicit INTEGER/SCALAR conversion is allowed. 

For READ Statements: 

» 

1 . Input is an optionally signed quantity , 

2. If an explicit decimal point appears in the input, it overrides 

the format; otherwise, decimal positiop. is implied by the 
<fofmat item>. " 


Example: 

READ (5) 

(A,B 

,C) IN 

interprets : 

|z<12 . 3 4 

as 

12.34 



as 

1.234 


b.1234 

as 

.1234 



■ " .-7 
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3* An exponent may be supplied of the form: 

E + <number> « » 

If either E or + is specified, the other may be omitted, 

4. For Input quantities, blanks are allowed preceding the sign, the 
first digit, E, +, and the first digit of the exponent. Other 
blanks cause a runtime error, 

5. There is no difference between E and F foniiats in READ statements. 
For WRITE Statements: 

a 

1. For F format items, the string printed is: 

-aaaa.bbb 


where n is determined by the second number in the format, and m is 
determined by the magnitude of the quantity to be printed. The minu^ 
sign is printed only if the quantity is negative, If the number of 
print positions required to represent the quantity is less than the 
field length, a zero is added to the left of thq decimal if no other 
digits are present there. Any additional positions are filled with 
blanks from the left. 

2. For E format items, the quantity pirinted is: 

-a.bbbEicc \ 


The minus sign is printed only if/ythe quantity is negative. One 
significant digit is printed to the left of the decimal point. This 
is zero if the quantity = 0. n is taken from the format item, 

3. If the field length is Insufficient, an error is sent and asterisks 
are printed in the field. 



10.1.4.5 A Fdrmat Items , 
data, 

SYNTAX: ’ 


A format items are used for character 


A fonwt tteipj 


A POMIAT If EM 


nuwber 


exMple: A7 


SEMANTIC RULES ; 


i; 


1. - <number> is an unsigned positiw integer representing the g 
field length. „ 

^ - , 0 ' - / 
For-READJ^-S*atement:s^^^ > .iu..-..-. 

1. If the field specified is greater than the declared 

length of the variable, the rightmost characters in the 
field are selected. Otherwise, the length of the CHARACTER 
variable is set to the field lei^gth. 

For WRITE Statements: 

1 . If the field length written is greater than the number of 
characters in the variable, blanks are added to the left. 
Otherwise , the leftmost characters are written to fill the 
field . " 

Example:" ? ' 

WRITE (6) ( PERSON j, HEIGHT^) IK 'AlO, X2 , F5 . 2 ' ; 

would produce: ^ 

BAGLEY 5 5. "57 

: ■ » ’ t : I ■ :■■■" 

coiwitm JO 77 


Note: BIT and CHARACTER conversion functions can be used 
with A format items for I/O involving bit variables. See 
Sections 6.5.2 and 6.5.3. 
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SEMANTIC RULE^ 

<number> is an unsigned positive integer repre, Renting the 
field width. 'V 

2. The interpretation of the <U forinat item> depends upon the data 
type of the., associated <variable> or <expression>‘ . 

for character strings , U<number> is equivalent to A<number> ; 

— for integers, tr<nuinber> is equivalent to I<number>; 

- for scalars, 0<nurober> is equivalent to E<number>.<number>-7. 
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SEMAN'llC RULES; 

O'-. 

1. <number> is an unsigned positive 




The effect is the same as TAB (<number>) , 
Example : ” 

READ (5) A in ’X5, 13'; 


If the input is: 
12345678 


then A becomes: 

678. I 

f/ 

if. 
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10.1.4.8 FORMAT Quot^ Strings , 
used for character output. 

SYNTAX : 


FORMAT quote %trin 9 s are 


FORMAT QUOTE STRINQ 


Cformat quote striny 




exantple: ''NOTHING IS MORE PRECIOUS THAN INDEPENDENCE AND PREEI^," 


SEMANTIC RULES: 



For 

READ Statements: 

'■ ■ ■ o 

1. 

Columns corresponding to FORMAT quote strings" are skipped 
in READ statements. 

For 

WRITE Statements: 

Q 

1. 

A double quote in the text is 
double quotes. 

represented by a pair of ^ 

2. 

<characters> is copied to the 

output line. 


Example: 



WRITE (6) ANS IN '"ANSWER 

= % 12'; 


would produce: 



ANSWER = 21 






10.1.4.8 P Format Items . P iQrroat xtems can be employed for 
most types ot numeric l/Oi They can be very useful for mixing 
character and numeric output data and specifying column align- 
ment. 

SYNTAX: * , 



P FORMAT ITEM 


extended 

character 


cxamplei p the answer h $$.$ 


SEt^ANTld*^ RULES : “ 

1. The P format item runs from the first character following 

the P to the first ' or'/' encountered (or the end of 
the format character string) . ’ 

2. Each set of consecutive '$'s> '.'s, and '*'s defines a 
numeric field corresponding to an INTEGER or SCALAR item. 

'♦' defines the\Ybeginning of an exponent. If more than one 
'. • or is present in a given numeric field, a runtime 
error is sent. 

3. More than one field is allowed, e.g. 

VJRITE(6) (NO, ARGl, ARG2 , ARG1+^,RG2) IN 'P TEST#$$ : $ . $$*$$5 + 

$.$$*$$ = $.$$*$$$'; 

a 

For READ Statements: 

1. Each field length is the number of '$*, and present. 

Other characters cause corresponding columns to be skipped. 











2. A decimal in the input field takes precedence. Other- 
wise, a decimal is placed by the ' . V, if present. 

3. An exponent may be supplii^^S^f the form: ^ 

E ± <number> 

If either E or ± is specified, the other may be omitted. 

4. Blanks are "allowed preceding the sign, the first digit, 
E, ±, and theyfirst digit 6fi the exponent. Other blanks 
cause a runtime error . 

Example: c q 

READ(5) “ (X,Y) IN 'PXXX$5, $$X$$ ' ; 
then if the input is: 

01234567890 ‘ 

then X would be set to 345.67 and Y to 90, • 


For WRII'E Statements: 

1. If a quantity to be printed is smaller than the specified 
cfj field width, blanks are appended to the left. If the 

quantity to be printed (including if needed) is larger 
than the specified field width field, a runtime error is sent 
and the first is filled with asterisks. 

2. All characters except '$', and ’ are printed. 

3 . I-f'’ an exponent xs called for , the number takes the form: 

-a.bbbEicc " 


A non-negative quantity prints a blank in place of the 
sign. The leftmost digit pirinted will be non-zero unless 
the value to be printed is exactly zero. The field widths 
i , j , and k are taken from the number of ”$" signs in , the, 
picture, i must be greater than zero and k must be large 
enough to hold the exponent. 


Example : 

DECLARE CHARACTER (100) , 

T INITIAL ( ' P TITLEl TITLE2 

D INITIAL ('P $$.$$ $$.$$ 

WRITE (6) IN T; 

WRITE (6) DATA ARRAY ^ IN D; 
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TITLE 3/ ' ) , 
$$.$$/'); 







would produce the following table: 
TITLE 1 TITLE2 T1TLE3 

98.72 -5.61 43.00 



1 * ♦ 

cp-Cmn S 17 26 



O 




10. 2 Random Access 1 10 and the FI LE Statement. 


Random access I/O is handled by means of the FILE 
stat^ent. In this access method iiidividual records on a 
file"^^ay be written, retrieved or updated. A unique ''record 
address" is used to specify the particular record on the 
file referenced. 


SYNTAX: 


FILE itattfiiffili 


basic 

ttttcmtnt 


arith exp 


FtLE(3,J + 2)*ALPHA^TO. 


SEMANTIC RULES : 

1. The statement^is an output PILE statement if <file exp> 
is »on the left of the assignment. If <file exp> is on 
the right, .then the statement is an input PILE statement 
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2. <file exp> sf^^ifles the random access I/O channel and 
record address to be referenced. <number> is any legal 
random access channel number. <arith exp> is any unarrayed 
integer or scalar expression. If the expression '^is scalarv 
its value is rounded to the nearest integer before use. 

A run time error occurs if its value is not a olegal re<j^r(|;, 
address. 


3. Any record on a random access file may be transmitted by 
a FILE statement. 


4. In the input PILE statement, <variable> is any variable 

usable in an assignment context. This specifically ^ 

excludes input parameters of function and procedure blocks. r> 

Moreover, <variable> is also subject to the following Z 

rules ; 

! o o" , 

• ; No component subscripting for bit and character 


• If component subscripting is present, „<variable> . 
must be subscripted so as to yield a single 
(unar raffed) element of the <variable>. 

• If no component subscripting is present, bu^t~a^ay 
subscripting is, then all arrayness must be subscribted 

"away. ' 

• BIT type structure terminals which have the DENSE 
attribute may not be used, due to packing implications. 
However, an entire stjnacture With the DENSE atti^ibute 
may be -used. 


5. 


• If the <variable> is a structure terminal or a 
minor structure node (but not if it is a major 
structure) and if the structure possesses multiple 
copies, then the number of copies must be reduced 
to one by subscripting. 

In the output file statement, there are no semanti<^^ 
reswictions on <expression>. 




6. Gomtfatibility between data written by an output FILE 
statement, and later reference to it by an input FILE 
Statement is assumed. 1^,e exact interpretation of compa- 
tibility is implementati^?;^ dependent. In general , the 
FILE statement transmits binary images ° of the internal 
data forms , so that compatibility will be guaranteed if J 
^'the <expression> of the output FILE statement and the 
<variable>\vOf the input F'lLE statement have the same d ait a 
type and organization, 




o 



. • o 


G ' 



■o 
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11. SYSTEMS LANGUAGE FEATURES^ 


11.1 INTRODUCTION 


The systems language features of HAL/S are described in this 
section. The features presented here are in three sections. 
The new Program Organization features are "Inline Function 
BlocJc^" and "%-macrosV A data-related feature of this 
systems language extension is the concept of "TEMPORARy 
Variables". The NAME Facility concerns a new concept in 
HAL/S, the addition of NAME variables pointing to data or 
blocks of code. 

The inf oration contained in this section constitutes 
an extension of material |>re_sented earlier. Accordingly, 
many of the syntax diagrams presented here are 
modified versions of earlier diagrams reflecting the 
extended features. Such modified diagreuns are indicated 
by appending the small leter "s" to the diagram number. 

11.2 PROGRAM ORGANIZATION FEATURES 

The addition of inline Function Blocks and "%-macros" to 
HAL/S extends the information presented in Section 3 
concerning program organization. Inline functions are a 
m^ified kind of user function, in which invocation is 
simultaneous with block definition, %-macros may be 
viewed as a class of special purpose implementation 
dependent built-in functions. 




11.2,1 JnJUnt tuncxAXjn Mocki 

The HAL/S Inline Function Block is a method of _ 
simultaneously defining and invoking a restricted version 
of the ordinary user function construct. Its primary purpose 
is to widen t}%e utility of the parametric REPLACE statement ^ 
described in Section 4.2. Its appeeirance is generally in the 
form of an operand of an expression. 

^ An Inline Function Block, like othei blocks, has a new 
level of name scoping and error recovery. 

SYNTAX: 


function 


FUNCTION 


typcsptc 


sutemtnt 



•xomplet 

IF X -= Y THEN R = FUNCTION VECTOR; 

DECLARE A, B; 

A = 3X + Y; ^ 

B = x/Yf '.r-vf = 
RETURN VECTOR( A, B,0^; 
CLOSE? 

jh - R*V; 









SEMANTIC RULES: 


X. The syntadtic form is actually equivalent to that^ of a 
function block except that: 

o' 

a) The <§ inline function> has no label;" 

b) The <§ inline £unction> has no pareuneters; 

^ c) The <§ inline function> definition becomes an operand 
in an expressioh. 
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The semantic rules tor. an <Sinline £unc t ion v block 
de^nition are the Same as those for the <£unction 
^ock> definition des<3^i^sd is Section 3.3, subject 
restrictions listed below. ' 


A <£iiiline function> may not contain the following 
Syntac^tical ;fo/r1iVS:i ; 


foritia^ of l/Q statements 


''-i 


• All forms of reference to user-defined PROCEDURE 
and FUNCTION blocks; 


</' 


Real Tiotie statements. 


o, '- 


A < § inline ,f unctioni« may only contain , one form of 
nested block, the <dp<iate block>. The following 
block forms are thus exclude'd: 


• i <tfunction block> definitions; 

• <procedure block> definitions; 

• Further nested <§ inline function>s. 


■h 


In use,^ the” following semantic restriction holds: 
<§inline £unction>s may not appear as operands of 
the subscript or exponent expressions. 


@ 


The < sin line function> falls into one Of the following 
four^ categories : 




<arith inline> 


<bit inline> 


- <type spec> specifies an 
inline function of an arith- 
metic data types SCALAR, 
FIXED, INTEGER, VECTOR, 

VECTGRF, MATRIX, or MATRIXF. 

0 

- <type spec> specifies an ^ 
inline function of a bit 

..type: BOOLEAN or BIT. 


O 


. (v> 
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<char inline> « <type speo specif an 

inline function of the 
CHARACTER data type. 


<struct inline> 


H <type speo specifies an 
- inline f\.)nction with a 
structure type specifica- 
' tion. 


The use of inline functions a^H^perands of HAL/S 
expressions is discussed in Section 11.2.3. 






11.2.2 %-macho lidieJimcu 

The HAL/S %-macro facility provides a means of 
adding functional, special-purpose extensions to the 
language without ts^uiring syntax changes or extensive 
rewiting of the com|^iler programs. The details of the 
implementation of any ^ given %-macro will depend upon 
its nature and purpose. Possible options include inline 
generation of code or links to an external routine 
performing the processing of the %-macro. 

The syntax of the %-macro reference is presented 
in this section. The invocations of %-macro routines in 
various expression or statement contexts is described 
below in Sections 11.2.3 and 11. 2.4. \ 

\ 






0 


SEMANTIC RULES: 




1. The § -macro ref erence falls infb one of the i^dllowing 
five categories based upon data type: 

• <arith %-macro> is a reference to a § -macro which 

returns an arithmetic value of INTEGER, SCALAR 
FIXED, -;;^ECTOR, VECTORF, MATRIX, Or mTRIXP 
data type . 

• <bit %-macro> is a reference to a § -macro which^ 

returns a bit string value. 

I 

•l <char%-macro> is a reference to a § -macro which 
j re|:urns a value of the CHARACTER data type. 

•! < s truct %-macro> is a ref erenoe to a § -macro %hich 
returns a structure data value. 

• <typeless %-macro> is a reference to a §-macro 

which performs some systems function but 
'' returns no value and may only be referenced 

from a %-macro cell statement . (See Section 
, 11.2.4 below) . 0 


Available %-macros in any implementation will be 
provided in the appropriate User's Manual. 


2. The <%label> is a reserved word beginning with the 

character "5" which identifies the %-macro in question 
The character "%" distinguishes %-macro names from all 
other reserved words in the HAL/S language. 
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3 . A series of one or more arguments of the %-macro 
reference may be supplied. The type# organization 
and number of the arguments supplied to the %-macro 
must be consistent with the requirements of the 
routine. 

4. Details pf <%-macro arg>s will be supplied f^th the 

definition of a given %-macro, -y 



11 .2, 3 a OpeAond He.^eA.znctfJnvoccuUoni> 

Inline Function Blocks are always invokd^at the 
point of their definition as operands of <expression>s. 
%-macros are also invoked as operands of <expression>s 
when they are of a definite data type and thus return 
a value. Similar modifications of several syntax 
diagrams from Section 6 add these features to arithmetic, 
bit, and character operands, and to structure expressions. 


SYNTAX OP ARITHMETIC OPERAND 


•rilhfTMtteofmind 



normat function 


arith tAnmiion 


aritH % macro 




SMANTIC RULES: 

, This syntax diagram is a systems language extension 
of the arithmetic operand diagram in Section 6.1.1. 

The semantic rules of Section 6.1.1 apply to this 
revised diagram. 

' 

, <arith inline> is an inline function block which has an 
arithmetic <type speo in its header statement . 

- <arith % -macro is a reference to a ^ -macro which 
returns an arithmetic value (See 11.2.2 above) . 
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SYNTAX OF BIT OPERAND: 


procttt*«vfm nam« 


bil literal 


normal function 


btt conversion 


bit pseud otvar 


bit inline 


bit Imacro 


SEMANTIC RULES: 

1. This syntax diagram is a systems language extension 
of the bit operand diagram in Section 6.1.2. The 
corresponding semantic rules found in Section 6.1.2 
also apply to this revised diagram. 

2. <bit inline> is an inline function block which has a 
bit string (BOOLEAN or BIT) <type speo ih its header 
statement. 


<bit %macro> is a reference to a %-macro which returns 
a value of the BIT or BOOLEAN data types. 
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SEMANTIC EULES: 


1. This syntax diagram is a systems lamguage extension 
of the character operand diagram in Section 6 . 1 . 3. 

The corresponding semantic rules found in Section 
6,1.3 also apply to this revised diagram. 

2. <char inline> is an inline function block which has 
a CHARACTER <type spec> in its header statement. 

3. <char %macro> is a reference to a %-macro which returns 
a value of the CHARACTER data type;; 




t 

I 

is 

I 

‘i. 

f 

I 
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SYNTAX OF STRUCTURE EXPRESSION 



SEMANTIC RULES: 

1. This syntax diagram is a systems language extension of 
the structure expression diagram found in Section 6.1.4. 
The semantic rules found in Section 6.1.4 also apply to 
this revised diagram. ^ 

2. <struct inline> is an inline function block which has a 
structure <type speO in its header statement. 

"3. <struct %macro^ is a reference to a %-macro which retTorns 
a value Of a structure data type. 
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1i,2.4 Tm t~UaciU) CcuZ Siatmznt 

The invocation of a typeless %-inacro is 
performed by a <%»macro call statement>. 


SYNTAX 



SEMANTIC RULES: 


1. The <%-macro call statement> invokes execution of the 
typeless %-macro being referenced,*===^. 

2. The effect of this statement is dependent upon the 
details of the %-macro being ref erencecii. 








. 

F i 


II. 3 Temporary Variables 


The extension of HAL/S data concepts to include a 
TEMPORARY variable form for use within DO groups is defined 
within the systems language facilities. The object of 
incorporating the TEMPORARY variable is to increase the 
optimization and efficiency of the object code produced by the 
compiler. Depending upon the details of the object machine, 
a temporary variable might be stored in a CPU register or a 
high-speed, scratchpad memory location rather than in the 
slower main storage. Coding efficiency may also be achieved 
with temproary variable because the instructions needed to 
access register or scratchpad memory values are genei^^lly more 
compact. Since the existence of a temporary variable is 
confined to a DO group (from DO header statement to the END 
statement), these forms bep<xne highly localized control Variables 

If a temporary variable appear^ in a REENTRANT block, v 
each process simultaneously executing the block gets its 
own temporary variable . 


11.3.1 nmmy VaJuabm 

. a ■ ’ 

Regular TEMPORARY variables are decrared In ^TEMPORARY 
statements following the DO statement whiqh begins a DO... END 
statement group and preceding the first executable, stat^ent of 
the DO... END statement group. The following diagram is a 
systems language extension of the DO... END statement group 
in Section 7.6. 


i o 

■ 

ii 
j 



SYNTAX: 











o 


/ 

SEMANTIC RULE: « 

1. " The TEMPORARY declaration may be included as part* of any 
DO group except a DO CASE group. U^e of TEMPORARY 
variables within nested DO groups o^ a DO CASE is allowed . 


The TEMPORARY Statement is a special purpose data declar- 
ation used to create TEMPORARY variables for general use within 
the DO gxotxu syntax as described above. Its form compares very 
closely to ‘roat of the DECLARE statement in Section 4.4. 



SYNTi^: 




f= 

SEMANTIC RULES I 



1. In the < temporary statement>, <attributes> may define 
the <identifiers> to be of any data type except EVENT. 

X47 I 2. <attributes> may on3;^specify type, precision, scaling 
• and arrayness. 

3. No minor attribute is legal. 


4. The name of <identifier> may not duplicate the name 
of another <identifier> in the same nzune scSbpe 
(procedure, function, or other block name) or of another 
temporary in the same DO. . .END group. 


ORIGINAL PAGE IS 
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11.3.2 Loop TEUPOmV Vcouabtu 

o The Loop TEMPORhRY variable form is used in the context 

of the DO FOR group and is declared by its specification in a 
DO FOR statement. The following two syntax diagrams are m<^ifi 
cations of the discrete DO FOR and the iterative DO FOR 
syntax diagrams. 

ft 

SYNTAX: 


dlimw OO ran iMpTUHrailARV nriabli Min 


TaWOMRY )— ( mmtUim 



SYNTAX 



ttMMtM DO f OR with loop tEMTORAR V vw i«W* kntex 


TEMPOIVARY H 
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SEMANTIC RULES; 

0 

1. All the semantic rules for DO FOR statemenl^s which are 
given in Section 7.6,4 and 7.6.5 apply as well to the 
corresponding Loop TEMPORARY forms. Additional rules for 
Loop TEMPO^^WY variedsles are, given below. <~> 

2 . The Loop TEMPORARY variable is defined in ihe DO FOR 
statement; a loop TEMPORARY variable is always a 
single precision INTEGER variable. 

3. The scope of the Lt^op TEMPORARY is the DO FOR group of 
the DO FOR statement which defines the varieible. 

4. The <identifier> name used for the loop TEMPORARY may not 
duplicate the name Of another <identifier> in the same 
name scope, nor may it duplicate the neune of another 
TEMPORARY variable in the same DO ... END gr^up. 


o 





/ 


! 

I 

f 


o 


P 




i 




o 


i 
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11.4 The NAME Facility 




This section gives a definitive description of the 
HAL/S NAME facility. This facility is designed to fill 
the system programmer's need for a "pointer" construct. 

Its basic entity, is the NAME identifier: a NAME identifier 

"points to" an ordinary HAL/S identifier of like attributes . 
The "value" of the NAME identifier is thus the location of the 
identifier pointed to. (An "Ordinary" identifier is a HAL/S 
identifier without the NAME attribute) . 


11.4.1 lde.nti^ZeAA with tho. NAME attfuJbuix. 


Identifiers declared with the NAME attribute become 
NAME identifiers. NAME identifiers may be declared with 
the following data types: 


INTEGER 


CHARACTER 

SCALAR 


EVENT 

PIXEb 


STRUCTURE 

VECTOR 


PROGRAM 

VECTORF 


TASK 

MATRIX 


0 . : - 

MATRIX? 



BIT 



BOOLEAN 
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The following diagram is an extension of the DECLARE state- 
ment syntax "diagram in Section 4.4. The modification shows 
how the keyword NAME is used in such a declaration to state 
the NAME attribute. 


SYNTAX: 



o-:.' 


c 





GENERAL SEMANTIC RULES: 

1.^ The following <attrlbute>s apply to the NAME ^r^riable 
^ itself and bear no relationship to the ordina^ 

identifier which is pointed to at any given time during 
execution:’ 



-:.i 

e The <initialization> attribute (if supplied^ refers 
to the initial pointer vaLue of the NAME variable 
itself. 

e static/automatic refer to the mode of initialization 
' of the NAME variable itself on’ entry into a HAL/S 
*' block . - 

e ^DENSE/ALIGNED apply to the actual NAME varisdsle when 
it is defined by inclusion in a structure template. 

() All other legal attributes desc^jbe the characteristics 
I of the ordinary variables tb^Which the NAME variable may 
point. Except as noted below, these other attributes must 
always match, the corresponding attributes of the ordinary 
vari^les to' which the NAME variable points? compilation 
errors will ensue if this is not the case. 

2. The ACCESS attribute is illegal for NAME variables? its 
absence does not prevent NAME identifiers from pointing 
to ordinary identifiers with the ACCESS attributes^ and 
matching is not required in this case. 

3. There must still be consistency between declared type, 
attributes, and factored attributes just as is the case 
for ordinary identifiers a^ described in Chapter 4jj of this 
Specification. 







o 
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SEMANTIC RULES (Data NAME Identifiers): 

1. Arrayness Specification - in general the arrayness 
specification of a NAME identifier must match that 
of the ordinary identifiers pointed to, in both 
number and size of dimensions. 

2. - Structure Copy Specification - in general the number 

of copies of a NAME identifier of a structure type 
must match that of the ordinary identifiers pointed 
to 

3. The use of the array specification or structure 
copies specification is excluded from declarations 
of NAME formal parameters. 

4. ^Structure Type - if a NAME identifier is a structure 

type it may only point to ordinary identifiers of 
structure type with the same structure template . Q 



examples of data NAME variables 


DECLARE X ARRAYI3) SCALAR, 


YARRAY(4), 

Z NAME ARRAY(4) SCALAR; 


DECLARE P EVENT; 

DECLARE EVENT LATCHED, V, VV NAli^lE; 


z may point to Y but not X 


c ^ 


5. For any unarrayed character string name variable, the 
form of maximum length specification may be used^. 
This is an extension of the use of the notation 
which applies now in general to character name variables 
as well as to formal parameters. 


6. Range Specification ^ if the NAME identifier has a range 
specification, then it must match that of the ordinary 
identifiers pointed to. If the NAME identifier has no 
range specification, then no match is required. 

7. Scaling specification - if the NAME identifier and the 
ordinary identifier pointed to both have defined scalings, 
the scalings must agree. 
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The Label Declarative Attributes available for use in declaklcing 
NAME identifiers which point to NAL/S block forms have been 
modified to include PROGRAM and TASK keywords and to exclude 
PROCEDURE and PUNCTION keywords. The following syntax diagram 
is substituted for the Label Declarative Attributes diagram in 
Section 4.6 when declaring NAME identifiers which point to 
HAL/S blocks. 


SYNTAX: 




SEMANTIC RULES (Label NAME Identifiers): 

a. <lnitialization>, STATIC or AUTOMATIC, DENSE or ALIGNED 
may only be applied to the <rabel declarative attributes > 
of identifiers with the NAME attribute. They are 
properties of the NAME and not of the identifiers 
pointed to. ^ 


2. The following rules apply to NAME <identif iers> of the PROGRAM 

and TASK types: 

e The NAME < identifier > of a PROGRAM or TASK type always 
points to'^a PROGRAM or TASK block, respectively, A 
corollary of this rule is that <process event>s are never 
referenced by NAME identifiers of the PROGRAM or TASK 
types . 

• Tl:^ only form of PROGRAM label declarations allowed 

are those with the NAME attribute. 

■’ ' ' - 

• The program NAME < identifier > must always point to an 
external PROGRAM block name; therefore a'block template is 
required for each PROGRAM which may be referenced by a 
NAME value. 


11,4,2 The. NAME AtVUbute .in St/iuctuxc Tmptate^ 

The NAME attribute may appear on any structure terminal 
of a structure template. The following syntax diagram shows 
how the keyword NAME is used to state the NAME attribute. This 
diagram is a systems language extension of the Structure Template 
diagram. 


SYNTAX: 


Mniccurt WfnpM 1 


ftrtictur* 


STRUCTURE 


In general, the rules governing the formation of the structure 
template remain unchanged (see Section 4.3), 







GENERAL SEMANTIC RULES: 


1. Restrictions on a'tt;ributes discussed in Section 11.4.1 generally 
also apply to structure terminals with the NAME attribute. 

0 //" . ■ , 

2. No <initializa^^n> may be applied to terminals neither 
may the attributes STATIC/AUTOMATIC appear. 


3. NAME identifiers of any type (including program and task) 
may appear as structure terminals. Note that the NAME 
of an EVENT may appear in a structure even though the 
EVENT itself may not. 


154 


4. The REMOTE attribute may be applied to a structure 
terminal with the NAME attribute unless it is of 
EVENT type. 


SEMANTIC RULES: Nested Structure Template References 

1. Nested structure template references are special instances 
of structure terminals. The manner of their incorporation 
into structure template definitions is as described in 
Section 4.3 via the <type speo, 

0 

2. Such references are permitted to use the NAME attribute. 

If the NAME attribute is present, the following points are 
to be noted: 

• Specification of multiple copies is still not permitted. 

• The reference may be to the structure template being 
defined (and of which the reference is a part) . The 
implications of this are discussed later. 



0 

examples of structure NM1E identifiers: 



STRUCTURE A: 

I X NAME PROGRAM, 
lY SCAUR, 

IZ NAME SCAUR, 

1 ALPHA NAME A-STRUCTURE; 



DECURE P A-STRUCTURE; 
DECURE PP NAME A-STRUCTURE; 


o 

P.Z is a NAME identifier which may point to 
P.Y 



PP is a NAME identifier which may point to 
P 

PP. Z is a NAME identifier which may point to 
P*Z which is itself a NAME identifier 
pointing somewhere. T|;is is an instance 
of double indirection. 



P. ALPHA is a NAME identifier of A- structure type. 
The consequences of this are discussed later. 



11.4.3 Ve.cIaAcLta)m oj Tewpo/to/uea 


No identifier declared in a TEMPORARY statement may 
possess the NAME attribute. No such identifier of structure 
type may have a template which contains one or more structure 
terminals bearing the NAME attribute. 




11.4.4 The. 'VeA.eieA.enced' UAe S/Aple NAME Jdentii<e/u 

Simple NAME identifiers are those which are not parts 
of structure templates. 

C\ 

If a simple NAME identifier appears in a HAL/S 
expression as if it were an ordinary identifer, then the value 
used in computing the expression is the value of the ordinary 
identifier pointed to by the NAME identifier. Similarly, if 
a simple NAME identifier appears on the left-hand side of an 
assignment, as if it were an ordinary identifier, then the value 
Of the right-hand side^Hs assigned to the ordinary identifier 
pointed to by the NAME identifier. These are examples of the 
' deif ef erenced ' use of NAME identifiers. 


Whenever a NAME identifier appears in a HAL/S 
construct as if it were an ordinary identifier, the 
dereferencing process (to find the ordinary identifier 
pointed to) is implicitly l>eing specified. Specifically 
this still takes place when a subscripted NAME identifier 
appears as if it were an ordinary identifier. Here 
the dereferencing takes place first, and then the 
subscripting is applied. to the ordinary identifier 
pointed to ; 


examples of (lereferenced NAME variables 

DECURE VECTORO), X, Y NAME; 
DECURE P NAME TASK; 

Q: TASK; 


CLOSE; 


if Y point? to X/ and P to Q then - 


TERMINATE P; 
Y = Y*Y; 


Means terniinate Q. 

Puts th4\ cross product 
of X witfi X in X. 

Puts the third element of 
X into the first element. 


A special construct to be described iR.> Sections 11.4.5 
and 11.4.6 is required to reference or change the value 
of a NAME identifier (as opposed to referencing or 
changing the value to which it points) , 
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ir 


o 


11,4.5 Re^e^eneing NAME Valut& 



The value of a NAME identifier is referenced or 
changed by using the NAME pseudo**f unction. This pseudo- 
function must also be used in order to gain access to 
the locations oz^rdinairy HAL/S identifiers. The locations 
r, or values so indicated will be called NAME values. The 
necessity also arises^or specifying Null NAME values. 

The following syntax diagram shows both the NAME 
pseudo-function construct as used for referencing NJ^E 
values, and the construct for specifying Null NAME Values . 


o 





SEMANTIC RULES : 

1. <sub id> is any ordinary identifier, except an input 
parameter, a minor structure, an identifier declared 
with CONSTANT initialization, or an ACCESS-controlled 
identifier to which assignment access is "denied" or 
not asked ^^f or. <sub name id> is any NAME identifier. 

,2. Either of the above forms may possibly be modified by 

subscripting legal for its type and organization. Note, 
however, the following specific exceptions: 

0 
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9 No component subscripting is allowed for bit 
and character types. 

• If con^onent subscripting is presents <sub id> or 

<sub name id> must be subscripted so as to yield 
a single (unarrayed) el«nent. ^ 

• If no component subscripting is? present, but array 
subscripting is , then all arrayness must be sub- 
scripted away. 


example: 


DECURE V NAME ARRAYO) VECTOR; 

NAME(V J 

is illegal since it 

•:1 

violates the second excep- 
tion of semantic rule 3 above. 


Any < sub id> must have the ALIGNED attribute. 

NAME < identifier >s may not be declared with the ACCESS 
attribute (see Section 11.4.1, rule 2). This does not, 
however , imply that the NAME facility is independent of 
the ACCESS control: NAME references to <sub id>s with 

ACCESS control will compile without error only if 
implementation dependent ACCESS requirements for.'^ 

<sub id> are satisfied. 

If <sub id> is unsubscripted, the construct delivers 
the location of the ordinary identifier specified. If 
it is subscripted, the construct delivers the location 
of the part of the specified identifier as determined 
by the form of the subscript. Subscripting can cliange 
the type and dimensions of <sub id> for matching purposes. 

If < sub name id> is unsubscripted, the construct delivers 
the value of the NAME identifier specified. If it is 
subscripted, the value of the NAME identifier is taken 
to be the location of an ordinary identifier of compatible 
attributes, and the subscripting accordingly modifies the 
location delivered by the construct. 
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The two equivalent forms NULL and NAME (NULL) 
specify null NAME values. 


examples; 

DECLARE X SCALAR, 

V VECTORO), 

^ NX NAME SCALAR. 
NV NAMEVECTORO); 


NAME(x) yields the location of X. 

name(nx) yields the value of NX (i.e. the 
location pointed to by NX) . 

NAMECV^) yields tM location of the second 
element 6f V. 

NAME(NV3) yields the location of the third 
element of the vector pointed to 
by NV. 
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11,4.6 Changing NAME Vatuu 

The value of a NAME identifier is changed by using 
the NAME pseudo- function in an assignment context. The 
following syntax diagram shows the NAME pseudo-function 
used for assigning NAME values: 


SYNTAX: 





o 


SEMANTIC RULE: 

I. <name id> specifies any NAME identifier except an 

input parameter, whose NAME value is to be changed. 
<name id> may not be subscripted (except as noted 
in Section 11.4,11) . 

example; 

DECURE X NAME MATRIX; 

NAi’lE(X) in assignment content specifies 
that a new value is to be given 
to X. 

/ : ' 

I I . 4.7 NMiE AsiXgment Statmmt6 

The NAME assignment statement is the construct by 
which NAME values are assigned into NAME identifiers. 
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OHiGlNAi: TAQE r 
OF POOH 



SYNTAX 



SEMANTIC RULES: 

1. The <name re£erence> and <neune assign>s must posdessr 
arguments whose attributes are compatible in the 
sense described in Section 11.4.1. 


11.4.8 NAME VcUue. CompculSdni 

The values of two <name reference>s may be compared 
to one another. 


SYNTAX! 



SEMANTIC RULES : 

1. This <coniparison> may be used in any syntax where 

ether forms of <comparison> may be used, for example 
in a <conditional operand > or as the <condition> 
controlling a DO WHILE. 
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i: 

I 2. Both <nane reference>s must possess^^^uments whose 

t <attributes> are compatible in the sense described 

i in Section 11.4.1. 


examples: 


DECLARE X SCAUR, / 

NX/NAME SCAUR: 

• 

NAME(NX)-NAME(X) ; 
• 

value of NX is location 
of X (NX points to X) . 

IF NAME(NX)* NULL THEN 

RbURN; 

0 

. \ 

xf NX contains a null value 

(points at no location) then 
retTirn. 



I U.4.9 Angvmint CoMldeAatiom 

NAME values may be passed into procedures and 
functions provided that the corresponding formal para- 
meters of the blocks in question have the NAME attribute . 
The following two syntax diagrams are systems language 
extensions of the earlier <normal function> and <call 
statement> syntax' diagrams. 

SYNTAX: 







SYNTAX 



SEMANTIC RULES: 

1. The formal parameters corresponding to <name reference> 
or <name assign> arguments of these block invocations 
. must possess the NAME attribute. 


The attributes of <name reference> and <name assign> 
arguments supplied in the <normal function> reference 
or <call statement^ must be compatible with those of 
the formal parcimeters in the same sense as described in 
Section 11.4.1. . 


3. If the argument of the procedure or function invocation 
is not a <name referenco then the corresponding formal 
parameter must not have the NAME attribute . ^ ^ 
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examples: 

DECLARE XI SCALAR. 

X2 NAWE SCALAR; 


P; PROCEDUREIA. B) ASS IGNIC, DH 
DECWRE SCAUR, A NAME, 

B, 

CNAME, 

D; 

NAME(C) • NAME(A); 

NAME(C) - NAME(B); illegal - B is an 


input paraiu^ter 


CLOSE; 


NAME(X2) - NAME(Xi); 

CALL P (NAME(XI); XI) ASS IGN(NAME(X2), XI); 


11.4.10 Jttitiatczatcon 

V name laentifiers way be declared with initiali- 
zation \o point to some particular identifier. Thfe 
form of NAME initialization is as follows; 

SYNTAX: 


NAME initiatiution attrib)iU 


Initialization 


initial HI 


nanw r«(er«nc* 


SEMANTIC RULES: 

1. The arginftent of the <name reference> jmust be a previously 
declared < sub name i^> or < sub id> with <attributes> 
compatible with the NAME identifier being declared. ^ 






3. Uninitialized NAME identifiers will have a NULL 
NAME value until the first NAME assignment. 

4. The argument of a <name reference> may not itself 
possess the NAME attribute. 


11.4.11 Notzi on NAME Vata. and S^'iucCtw.ei 

„ The previous sections have introduced the various 
syntactical forms and uses of the NAME attribute , <name 
assign>s^ and <name reference>s. The use of these NAME 0 
facilities with structure data merits further explanation 
since the implications of the various legal combinations are 
not always immediately apparent. Therefore, the purpose of 
this section is to continue further discussion of various 
aspects of NAME and structure usage by providing several 
examples. 


STRUCTURE TERMINAL REFERENCES 

C€> ^ 

Consider the structure template and structure data 
declaration below: 


STRUCTURE A: 

1 C SCALAR, 

1 B NAME ArSTRUCTURE; 

DECLARE A-STRUCTURE, Zl, Z2 , Z3; 

Zl.B is a NAME identifier of A-structure type: its NAI4E 

value may be set to point to Z2 by the assignment 

NAME (Zl.B) = NAME(Z2); 

If this is done then it is legal to specify Zl.B.C as a 
qualified structure terminal name. The appearance of B in 
the qualified name causes an implicit dereferencing process 
to occur such that if Zl.B.C is used in a dereferencing context 
the ordinary structure terminal a^ctually referenced is Z2.C. 

If the NAME value of Zl.B is changed by - 

NAME (Zl.B) = NAME(Z3); 

then the appearance of Zl.B.C in a dereferencing context 
causes Z3.C to be referenced. 


Pictorially: 



Now Zl.B.B is itself in turn a NAME identifier of A-^tructure 
type, so that if the NAME assignment 

NAME(Zl.B.B) = NAME(Z2)j 

is executed,' then Z2.C may be referenced by using the qualified 
name Zl.B.B.C in a dereferencing context, 

Pictorially: 


a 



Clearly this implicit dereferencing in qualified names can extend 
chains of reference indefinitely. A particular consequence is 
the creation of a closed circular chain, if the following NAME 
assignment statements: 

NAME(Zl.B) = NAME(Z2); 

NAME (Zl.B.B) = NAME(Zl); ^ ^ ^ ^ ^ 

are executed, then pictorially the following Closed loop is 
set up: 



Care must clearly be taken when using this implicit multiple 
dereferencing f sc that all links in the chain have previously 
been set up. 

B4PLICATI0NS OF SUBSCRIPTING^, STRUCTURE TERMINALS 

Using the same A-structure template as before, 
the following declarations are legal: 

DECLARE A-STRUCTURE (3) , Yl,Y2,Y3,Y4; 


One ox more copies of Yl.C may be referred to by subscripting, 
for example : 




. Yl.C 


2 AT 2; 


(optional semicolon fot clarity) 


Note that now Yl.B is a NAME identifier of A-structure type 
with 3 copies . One or more copies of it may therefore be 
assigned a NAME- value at one time. For example: 

NAMECYI.B 2 2^ “ 

In this assignment, the left hand side has arrayness: two 
copies of the Y1 structure. As a^' result, two values will 
be defined by the statement. However, the right hand side 
has no artayness, because the object pointed to is Y2 2 at 1 
This ds a two copy section of the structure Y2, with a 
unique starting location . 



Notice that in the above NAME assignment a subscripted <name id> 
appears as argument of the left-hand side NAME pseudo-function. 
Subscripts so appearing are legal only if they can have the 
interpretation exemplified. The subscripting employed must 
also be unarrayed, as wts mentioned earlier. 
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Further indirection may thJn be set up;*? thus for example: 

NAME (Yl. B .62 ) = NAME (Y3j^ ) ; 

Here the subscript 2 on the left-hand argument refers to copies 
of Y1 (th^s can be its only interpretstion) . Hence/ by virtue 
of the fact that YI.B 2 has previously been set up to point to 
Y 2 i, this assignment causes Y 2 .Bi to point to"^3]_. 

Arrayness will appear on both sides of a NAME Assignment 
Statement only when the assigned reference terminals of 
both sides possess the NAME attribute within structure 
variables with copies. 

Consider the template: 

STRUCTURE AA: 

1 C NAME SCALAR/ 

1 D NAME VECTOR; 


And the declaration: 

DECLARE AA-STRUCTORE ( 3 ) / Y Y1 / Y Y2 ; 

If the terminal element YY2.D is assigned td the terminal 
element Y Y1 . D , the NAME as signment "Is arrayed since both 
sides contain three copies . 0 

Thu(s ; > 


NAME(YYl.D) = NAME (YY2 . D ) ; 

causes the name values of YY2.D found in the three copies 
of YY2 to be transferred to the corresponding name variables 
in YYl.D. All the usual rules governing arrayed assignments 
apply in this case. 


O' 

.4] 
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MANIPULATING STRUCTURES CONTAINING NAME TERMINALS 


Since the NAME attribute may be applied to structure 
^terminals , a definition of operations performed on such 
°NAME terminals in ordinary structure assignments, compari- 
sons and I/O operations is required. The following general 
rules are applicable: 

e For assignment statements and comparisons involving 
structure data with NAME terminals, operations are y 
performed on NAME values without any dereferencings 


examples: 

STRUCTURE IOTA: | 

1 LAMBDA NAME VECTOR, 

0 DECLARE ALPHA lOTA-STRUCTURE(IO); 

DECLARE BETA IOTA-STRUCTURE; ' ’ 

ALPHA BETA; 

As a part of this assignment, ' the vector 
identifier (or NULL) pointed to by BETA^ LAMBDA 
becomes the vector identifier pointed to 
by ALPHA^LAMBDA^ as if a <nnTne assignment 
statement> had been used. 

IF ALPHA ^ - BETA THEN CALL QUE UPDATE- 

In th?;S IF statement, the structure compari- 
son between the two variables (ALPHA 5 and 
BETA) is performed terminal by terminal as 
u^uai. For the NAME terminal LAM^|5A or each 
structure operand, the effect is tihe same 
as if a <name comparisons had been used: Equality 
for the corresponding NAME terminals exists if 
they both point to the same ordinary identifier. 
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For sequential I/O Operations ^ all NAME terminals are 
totally Ignored^ Name teminala can take part In FILE I/O 


examples: 


STRUCTURE OMICRON: 

1 ALPHA SCALAR, 

1 BETA ARRAY(25) IMTEGER SINGIE, 
I GAMMA NAME MATRIXdO, 10); 

stIucturetau; 

1 ALPHA SCAUR;^ 

1 BETA ARRAY(25) INTEGER SINGl£; 
DECLARE X OMICRON-STRUCTURE; 
DECiARE YTAU-STRUCTURE; 


READ(5) X; 

The structure variable X is an OMICRON^ 
STRUCTURE^ whose template includes the NAME 
of a 10 X 10 matrix (GAM:*1A) . Only the 
ordinary terminals are transferred from 
Channel 5 by this MAD operation — the value 
of. X. ALPHA and the 25 values required for 
X.BETA. The NAME terminal X, GAMMA is ignored^ 


READ(5) Y; 

I The structure variable Y is a TAU- STRUCTURE, 
who/|le template omits the NAME terminal GAMMA 
found in the OMICRON-STRUCTURE, but is otherv/ise 
identical. The effect of this READ statement is 
the samp as the previous statement as far as 
Channel 5 is concerned one value is read for 
Y. ALPHA and 25 values are read for Y. BETA. 




11.5 The EQUATE Pacilit 


This section describes the HAL/S EQUATE facility which 
allows a system programmer to assign an external neune to an 
element of a ilAL/S 'data area. 

Reference to HAL/S data items by HAL/S code is achiWed 
by use of HAL/S identifiers. ^When such references occur across 
compilation unit boundaries, the Block Template provides the 
information necessary to generate the reference properly. If, 
however, the unit making reference to a HAL/S data item is not 
a H^L/S code block, the Block Template facility is unavailable. 
It ^is under these latter circumstances that the HAL/S EQUATE 
facility may be us^d to make the location of a HAL/S data item 
available to an external, non-HAL/S code block. 


The. EQUATE Statement 


SYNTAX: 


EQUATE Statement 


EQUATE 

Statement 


EQUATE 

EXTERNAL 


( 

N 

identifier 

}-(t^ 

variate 






example; 

EQUATE EXTERNAL XYZ TO A; 
EQUATE EXTERNAL QRS TO S. T 


5 ; 4 , 3 : 1 , 6 ; 





SEMANTIC RULES: 


o 


o 


1. The EQUATE statement causes <identlfier> to become an 
externally recognizable label of the HAL/S <variable>. 

The manner in which this is done is implementation depen- 
dent. The EQUATE statement has the effect of raising 
the name of <identifier> to a global external level 

such that it is known to whatever binders, loaders, 
link-editors, etc.'^ are used by an implementation. 

2. The number of characters of the <identifier> which 

participate in the external name created is implementation 
dependent. o 

3. The EQUATE statement does not constitute a HAL/S declara- 
tion. This implies that <identifier> may appear in a 
declare statement and be u.^ed in any manner consistent 
with that declaration. In tHe absence of such a 
declaration, <identifier> is not declared ant'/ may not 

be used anywhere else in the HAL/S code. 

4. Duplication of <identifier>s among multiple EQUATE statements 
within a single Gompilation unit'^is subject to implementation 
dependent rules. 

5 . <variable> may be any HAL/S data item previously declared 
in the innermost scope containing the EQUATE statement. 

6. If <variable> is subscripted, all subscripts must be 

computable at compile time. ^ . 

7. The external name created by the EQUATE statement will be 
associated with the memory location of the first (or only) 
element specified by. <variable>. • 

8 . Attempts to associate external names with HAL/S data 
items which are not located ''integrally at addressable 
memory locations or discontiguous memory locations are 
subject to implementation restrictions. 


J- 
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IKS. 2 EQUATE Statwmt Ptacemnt 

The following diagram is a system language extension 
of the Declare Group syntax diagram in Section 4.1. The 
modification shows how the EQUATE statement fits into the 
declaration structure of HAI#/S. 


SYNTAX: 









A. SYNTAX DIAGRAM SUMMARIES 


A.l SYNTAX PRIMITIVE REFERENCES 


The syntax di%reuns in this Specification are numbered 
sequentially. The 'CONTENTS of the Specification state 
which diagreuns are in each section^ 

The following table shows where the HAL/S syntactical 
primitives (excluding reserved words and special characters) 
are referred to. 

NOTES: 

1. Primitives are listed in alphabetxcal order. 

2 . Numbers enclosed in [ J denote indirect references to 
the primitive. Explanations are given in the accompany- 
ing Semantic Rules. 


Syntactical 

Primitive 


<arith var narne> 


<argumcnfe> 
<lj!it literals 


<char li-teral> 


<char Var name> 


<GVent var name> 


<idontifier> 


Diagram 

Number 



Syntactical 

Diagram 

Primitive 

Number 

<label> 

48 

(continued) 

50 


51 


52 


53 


54 


55 


56 


57 


58 


59 


60 


61 


62 


63 


64 


65 


66 


68 


53s 


54s 


77 


47s 

<nucibor> 

13 


15 


16 


118) 


25 


63 


64 


65 


66 


68 


16s 


13 s 

< process-event name> 

27 

37 

-<teraplatG 

17 

<tcxt> 

12 

12.1 



7-13 

7-16 

7-17 

7-18 

7-20 

7-22 

7-24 

7- 25 

8- 4 
8-8 
8-10 
S-11 
8-13 

8- 14 

9- 3 

9- 7 

10- 3 
10-6 
10-10 

11- 15 
11-15 
11-31 
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C<p 
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A. 2 SYNTAX DIAGRAM CROSS REFERENCES 


The following table shows where non-primitive syntactical 
terms are defined and referenced. 

NOTES: 

1. Terms are listed in alphabetical order. 


2. <radix> ,i>s included even though it .has no syntactical 
diagram* because for the purposes of the Specification 
it was not regarded as a primitive. Its definition is 
included in the Semantic Rules accompanying %^e syntax 
diagrams where it is referred to. ~ 



Note that an "s" 
Language Diagram 


suffix^, identifies a' modified systems 
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Of POOR QUALITY 


Syntactical 

I>efinition 


Defined in 


References 



Diagram 



1 ' ■ ' 

<arlth conversion> 

39 

6 

6-28 

25,25 s 

<arith exp^ 

24 

6 

6-3 

15,17,18,22,23,25,28,32,39,51, 
53,54,57, 60 , 61,67,68,25s, 54s 

<arith operand> 

25 

6 

6-6 

24,25s 

<arith var> 

19 

5 

5-5 

20, 25, 53, 54, 25s, 54s 

<array sub> 

22 

5 

5-11 

21 

<arith inline:>, 

25s 

11 

11-8 

25 

o 

<arith % macro> 

£) 

25 s 

11 

11-8 

25 

<attributes>: 


■V> 

. <r 


data 

15 

4 

4-15? 

0 

label 

16 

4 

4-21 

16s 

name < 

16s 

11 

11-20 

44,45 

<basic statement>: 





assignment 

46 

7 

7-5 


name 

.75 

11 

il -27 

47s 

CALL 

47 

7 

7-9 

47s 

name 

47s 

11 

11-32 


CANCEL 

58 ! 

8 

8-8 


DO , . ‘^END 


7 ■ : 

7-15 i 


EXIT 

56 

7 

7-25 

fj 

EILE 

68 

10 

10-10 


GO TO 

56 " 

7 

7-25 

■ ^ ■ ■' ' 

name assign 

74 

. 11 0 V 

11-27 

75,76,77,47s 

null 

56 

7 

7-25 

ON ERROR 

63 : 

9 

9-3 









Syntactical 

Daflnltion 


Syntactical 

Defined in 

o 


Mzxnxwxon 

Diagram 

Section 

Page .. 


READ 

65 

10 

10-3 

,o 

ii 

READALL 

65 0 

10 

10-3 


REPEAT 

56 

7 

7-25. 


RESET 

62 

y . 

8 

8-14 


RETUIW 

48 

7 

7-13 


SCHEDULE 

57 

8 

8-4 


SEND ERROR 

64 

9 

9-7 


SET . 

62 

8 

8-14. 


SIGNAL 

62 

8 

8-14. 


TERMINATE 

59 

8 

8-10 


^ UPDA!^^ t^orxt:^ 

61 

8 

.9-13. 


WAIT 

60 

8 

8-11 


WRITE 

66 

10 

10-6 


<bit conversion> 

40 

6 

6-32 

27,21s 

<bit exp> 

26 

6 

6-8 

23, 27 , 33, 41,45, 52 , 53 , 54 , 27s (fS4s 

<bit inline> 

■ ■ ■ V.-. -'•} 

27s 

11 

11-9 

27 o ' 

<bit % macro> 

27 s 

11 

11-9 

27 

<bit qperand> 

27 

6 

6-9 

26,27s 

<bit pseudo-var> 

42 

6 

6-36 

20,27,27s 

<bit var> 

19 

5 

5-5 

20,27,27s 

<char Conyers ion> 

41 

6 

6-34 

29,29s 

u 

<char exp> 

28 

6 

6-11 

23,29,34,30,29s 

<char operand> . 

29 

6 

6-12 

28,29s 

<char var> 

19 

5 

5-5 

20,29,29s 













Syntactical 

Definition 


<char inline> o 

<char % macro> 
<closing> 

<comparison> : 

O 

arithmetic 

bit 

character 
structure 
<coropilation> 
<component sub> 
<compool block> ^ 

<compool header> " 
<CQmpool template> 
<condition> 
name 

<conditional^ qperand> 
<declare gr oup> 
<declare statement> 

. name 

<do statement>: 

CASE V 
discrete FOR 
temporary var 
iterative FOR , 


Defined in 

Diagram 

Section 

Page 

29s 

11 

11-10 

29s 

11 

11-10 

10 

* 3 

3-22 

32 

6 

6-16 

33 

6 

6-18 

34 

6 

6-19 

35 

6 

6-19 

1 

3 

6-20 

22 

5 

3-2 

5 

3 

5-11 

n. 

7 

3 

3-10 

6 

3 

3-14 

30 

6 

3-11 


Reference* 


31 


6-14 

11-30 30 

6 — 15 2 f 3 » 4 » 5 , 6,69 

4«3 ll,14sils 

4-14 

11-17 49,49s s 

7 - 17 
7-20 
11-15 
7-22 


OF. POOR QUAUTV 


OF /pOOE 










Syl^tactical 

Definition 


temporary var 
simple 
UNTIL 
WHILE 

<end statement> 
<equate statement> 

<event exp> 

<event operand> 
<event vrar> 
<expression> 

<f ile exp> 

<fUnction block> 
<function header> 
<functipn teroplate> 
< inline function> 
<initial list> 
<initiali 2 ation> 
name 

<i/o control> 
<name> 

r. - 

<name ref erence> 
<normal function> 
name 

<precision> 
<procedurfe block> 


Defined in 


Diagram Section Page 


11 


References 




11-15 

7-16 

7-17 

7-18 

7-24 49,49s 

11-40 11s 

37,57,60 

6-22 

36 

6-23 

20,27,37,62 


18,38,39,40,41,42,46,47,48,66, 

68,70 


10-101 68 

1,2,3,4,49,49s 




3- 

19 
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11 

11 
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26 

11 

-33 

10 

-8 

11 

^17 

11 
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6- 

24 

11 

-31 

6^ 

39 


3,6 













Syntactical 

Definition 


<procedure header> 
<procedure template> 
<program block> 
<program header> 


<% macro> 
typeless % macro 
<radix> 

<replace statement> 
parametric 
<scaling> 

<statement>: 

basic 


Defined in 


Diagr^ Section I Page 


Note 2. 



40,41 

11,11s 


temporary 
<structure exp> 


11-^14 

6--13 


<s truGture sab> 


<struct inline> 


<struct % macro> 


< structure template> 


29 as 


5-11 21 

*11'^11 29.1 
.11^11 29a 
4-10 11,11s 

.11-22 


<structure var> 


20, 23, is, 25, is, 29.1 


<sub exo> 


<sub name id> 


<subscript> 


<task b2;ock> 



19,39,40,41,42 

2,49,49s 














A. 3 SYNTAX DIAGRAM LISTING 


DIAGRAM # 


TITL^ 


PAGE 


unit of compilation 
PROGRAM block 

PROCEDURE, FUNCTION and TASK blocks 
UPDATE block ^ 

COlSiPOOL block ) 


3-2 

3-4 

3-6 

3-^8 

3-10 


block templates; PROGRAM, PROCEDURE, 3-11 

FUNCTION and COMPOOL templates 
simple header statement 3-14 

PROCEDURE header statement 3-15 

FUNCTION header stateme^^ 3-17 

Closing of block 3-lS 

declare group 4-3 

EQUATE statement placemen'w' in declare group 11- -i 
REPLACE statement 4-4 

structure template statement 4-9 

structure template statement/NAME attribute 11-22 
declare statement 4-12 

declaration statement/NAME attribute 11-16 

data declarative attributes 4-12 

' r, 

label declarative attributes 4-l£ 

label declarative attributes/PROGRAM-TASK 11-lS 

type specification 11-1 S 

Q.nitialization specification 4-22 

<yar>; arithmetic, bit, character, 5-5 

structxire, event variables o 
variable 5—5 

subscript construct 5-8 

component, array, and structure 5-1] 

subscripts 

expression 6-2 

arithmetic expression o 6-3 

arithmetic operand 6-6 

ar:y:hmetic operand inline function block/ 11-7 
i^-macros 


♦Note that an "s" stiffix identifies a modified Systems 
Language * diagram. 


A- 9 


DIAGRAM # 

° TITLE 

PAGE 

26 

bit expression 

6-7 

27 

bit operamd 

6-8 

27s 

bit operand inline function block/ 
%-macros o 

11-8 

28 ' 

character expression 

6-10 

29 

cheuracter operand 

6-11 

29s 

character operand inline function block/ 
%-macros 

11-9 

29.1 

structure expression., 

6-12 

29,1s 

structure expression inline function block/ 
%-macros 

11-10 

30 

conditional expression 

6-13 

31 

conditional operand 

6-14 

32 

arithmetic comparison 

d5-15 

33 

bit comparison 

6-17 

34 

character conparison 

6-18 

35 

structure comparison 

6-19 

36 

event expression?==^ 

6-21 

37 

event operand / 

6-22 

38 

normal function 

6-23 

39 

arithmetic conversion function 

6-27 

40 

bit conversion function 

1 .' 0 

6-31 

41 

character conversion -function 

6-33 

42 

SUBB|T pseudo-variable 

6-35 

43 

precision specifier 

6-38 

44 

basic statement 

7-2 

45 

IF statement 

7-3 

46 

assignment statement 

o 7-5 

47 

CALL statement 

7-9 

47s 

CALL statement with NAME 

11-32 

48 

RETURN statement 

7-12 

49 

DO... END statement group « 

7-14 

49s 

DO, ..END statement group/ temporary 
variable 

11-12 

50 

simple 'DO statement 

7-15 

51 

DO CASE statement ''' o 

7-16 

52 

DO WHILE and UNTIL statements 

7-17 

53 

discrete DO FOR statement , 

disctete DO FOR statement/ temper ary 1 

variable 

7-18 

53s 

11-14 

54 

iterative DO FOR statement 

7-21 

54s 

iterative DO FOR statement/temporary 
variable 

11-14 

55 

END statement 

7-23 


DIAGRAM jf 

TITLE 

PAGE 

56 

Other basic statements: GO TO, "null", , 
EXIT and REPEAT statements a 

7-24 

57 

SCHEDULE statement 

8-4 

58 

CANCEL statement 

8-9 

59 

TERMINATE statement 

8-11 

60 

WAIT statement ' 

8-i2 

61 

UPDATE PRIORITY statement 

8-14 

62 

SET, signal”, and RESET statement 

8-15 

63 

ON ERROR statement 

9-3 

64 

SEND ERROR Statement 

9-7 

65 

READ and READALL statements 

10-3 

66 

WRITE STATEMENT 

10-6 

67 

:S/o control function 

10-8 

68 

FILE statements 

10-25 

69 

inline function block 

11-2 

“ 70 

%-macro statement 

11-5 

■O 

71 

%-roacrQ call 

11-11 

72 

temporary statement 

11-13 

73 

NAME reference 

: 11-26 

74 

NAME assign 

11-29 

75 

NAME assignment statement 

11-30 

76 

NAME conditional expression 

11-30 

77 

normal function reference 

11-31 

79=/ 

NAME initialization attribute 

11-33 

, 80 

EQUATE statement 

3,1-40 


scaling 

6-39 

82 

FORMAT LISTS 

10-10 

83 

FORMAT CHARACTER EXPRESSION 

10-11 

84 

FORMAT ITEM 

10-13 

85 

I FORMAT ITEM 

10-15 

86 

F and E FORMAT Items 

10-16 

87 

A FORMAT ITEM 

10^18 

88 

U FORMAT ITEM 

10-19 

89 0 

X FORMAT ITEM 

10-20 

90 

FORMAT QUOTE STRING 

10-21 

91 

P FORMAT ITEM " 

■ ' -^i 

A-11 ^ 

10-22 









B. HAL/S KEYWORDJ? 


(/ 


II 

The following table of keywords excld^es built-in functions 
and %rinacro names. jl 




ACCESS 

EXCLUSIVE 

P RANGE 

AFTER 

EXIT 

! READ 

ALIGNED 

EXTERNAL 

tj READ ALL 

AND 


REENTRANT 

ARRAY 

FALSE 

REPEAT 

ASSIGN 

FILE 

REPLACE 

AT 

FIXED 

RESET 

AUTOMATIC 

FOR 

RETURN 


FUNCTION 

REMOTE 

,o 


RIGID 

■0 

BIN 

GO 

SCALAR 

BIT 


SCHEDULE 

BOOLEAN 


SEND 

BY 

HEX 

SET 



SIGNAL 

CALL 

IF 

SINGLE 

CANCEL 

IGNORE 

SKIP 

CASE 

IN 

STATIC 

CAT 

INITIAL 

STRUCTURE 

CHAR 

INTEGER 

SUBBIT 

CHARACTER 


SYSTEM 

CLOSE ' 

LATCHED 


COLUMN 

‘LINE 


COMPOOL 

LOCK 

TAB 

CONSTANT 


TASK 


MATRIX 

TEMPORARY 


MATRIXF 

TERMINATE 

DEC 


THEN 

DECLARE 

, NAME 

TO 

DENSE 

nOnhal 

TRUE 

DEPENDENT 

NOT 


DO 

NULL 


DOUBLE 


UNTIL 


OCT 

UPDATE 


OFF 


ELSE 

ON 

VECTOR 

END 

OR 

VECTORF 

EQUATE 

ERROR 

PAGE 

WAIT 

EVENT 

PRIORITY 

WHILE 

EVERY 

PROCEDURE 0 

WRITE 


PROGRAM 



1 142 


1 147 


147 




147 
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C. BUILT-IN FUNCTIONS 


I? 

HAL/S typically supports the following set of built-in functions. 
Minor variations may arise between implementations. 


ARITHMETIC FUNCTIONS 

0 arguments may be INTEGER or SCALAR types 

0 functions marked with an * also accept FIXED type arguments 

0 in functions with one argument, result type matches argument type 
(except as specifically noted) 

0 in functions with two arguments, unless specifically specified, 
result type is scalar if either or both arguments are scalar; 
otherwise the result type is integer 

0 arrayed arguments cause multiple invocations of the function, one 
for each array element - arrayness of arrayed arguments must match 

Name, Arguments 

Comments 

* ABS (a ) 

H 

If Of is of type fixed vn'th a defined 
scaling, then the result is defined 
to have the same scaling. 

CEILING (a) 

smallest integer > a 

DIV (a , /? ) 

integer di vision or//3 (arguments 
rounded to integers 

FLOOR («) 

largest integer(^ a 

MIDVAL (ariS,^) 

the value of the argument which is 
algebraically between the other two. 
If two or more arguments are equal , 
the multiple value is returned. 
Result is always scalar. 

MOD (a , /? ) 

a MOD /3 

ODD (a) 

TRUE 1 if Of odd ) result is 

FALSE 0 if a even / BOOLEAN 

REMAINDER (a , ) 

signed remainder of integer division 
a/ 13 (argument rounded to integer) 



ARITHMETIC FUNCTIONS (CONTINUED) 


Name, Arguments 


Comments 


ROUND (a) 

nearest integer to a 

♦SIGN (a) 

+1 

a > 0 



-1 

a < 0 


♦SIGNUMta) 

+1 

a > 0 



0 

a = 0 



-1 

a < 0 

n 


TRUNCATE (a) 

^ It. 

largest integer < | a | times 



SIGNUM (integer (a)) 














ALGEBRAIC FUNCTIONS 

• arguments may be integer, scalar, or fixed types - ^ 

conversion to scalar occurs with integer arguments 

• result type is scalar unless argument is fixed, in 
Which case result type is fixed 

p arrayed arguments cause multiple invocations of the 
function, one for each array element 

• only those functions marked with an * accept fixed 
arguments 

• angular values are supplied or delivered in radians 

• angular values of FIXED type are scaled by» ir 

Name, Arquments 

Comments 

* ARCCOS(a) 

cos”^a fa} < 1 

this returns an angular 
value . 

ARCCOSH(a) 

cosh”^a ~ 1 

* ARCS IN (a) 

sin”^a , }a| < 1 

this returns an angular 
value. 

ARCS INK (a) 

sinh“^ a 

* ARCTAN2(a,P) 

“IT < tan“^(a/3) < v 

„ Proper Quadrant if: 
a = k sin e i . 

0 = k cos e f ^ ° 

this returns an angular 
value. '' 

ARCTAN (a) 

tan”l a 

ARCTANH(a) 

tanh^^a faf < 1 

*COS (a) 

cos a 

this takes °an angular 
value. 

COSH (a) 

cosh a 

EXP (a) 

e« 

LOG (a) 

log^ a , a > 0 
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* SIN (a) fy 

• i ^ 1 

i M 

I'i i -! 

sin a 

this takes an angular 
V value. » 

SINK (a) 

1 : ! 

sinh a 

*SQRT (a) 

1 i 
i 

i 1 

/a o > 0 

c'the scaling- of the result 
is implementation de- 
1 pendent if « is of type 

FIXED 

TAN(a) 

i. 

1 >. ■ 

tan ot 

TANK (a) 

tanh a 










o 


i 




‘ 1 . 

H 


n 

i ' 

U 
i ; 

t: 







0 


VECTOR-MATRIX FUNCTIONS 


• arguments are vector or matrix types as indicated 

• result types are as implied by mathematical operation 


• arrayed arguments cause multiple invocation of the 
function, one for each array eluent 


[ 

Name, Arguments 

Comments . 

: ABVAL (a) 

1 : ! 

1 ' : O 

length of Vector d,, 

For VECTORF argument with a 
defined scaling, ABVAL (a) has 
the same defined scaling 

1 : ; “ — — — — — 

DET(a) ■ 

: , a 

determinant of square matr;^ a. 
The scaling for MATRIXF ai?^- 
ments is implementation^e- 
pendent 

INVERSE (a) ' 

^ r 

inverse of a ^nsingular square 
matrix a, ' ' 

The scaling for MATRIXF argu- 
ments is implemetation depen*^ 
dent 


■ 11 - 



TRACE(a) 



TI^NSPOSE(a) 


UNIT (a) 


sum of diagonal elements of 
square matrix a. 

For MATRIXF agruments with a 
defined scaling, the result is 
def ined to have the same seal- 
ing 

transpose of matrix a. ^ ^ 

For MATRIXF argumenyts v/ith a 
defined scaling, /the result is 
defined to have the same scaling 

unit vector in same direction as 
vector a. 

For VECTORF argument, the result 
is scaled at 2 ^ 




MISCELLANEOUS FUNCTIONS 

• argvunents are as indicated; if none are* ’indicated 
the function has no arguments 


• result type is as indicated 


Uame , 

Arguments 

Result Type 

A 

Comments 

CLOCKTIME 

scalar 

returns time of day 

DATS i 

j integer 

; ; ■ ■ i ' ’ 

returns dalte ( implementation, 
dependent format! 

ERRGRP 

integer 

:■ 

, returns group number of last 
error detected, or zero 

ERRNUM 


1 i ’ 4* ' 

I returns nximber of last error 
detected, or zero 

PRIO ; 

integer 

; returns priority of process 
calling function <> ' 

random 

RANDOMS 

scalar 

■ 0 

fixed 

returns random number from 
rectangular distribution over 
range 0-1 

; a3 ■ ; ' 

The scaling of the result of 
RANPOMF is undefined 

RANDOMS 

scalar « 

returns ramdom nvunber from 
Gaussian distribution mean 
zero, variance one. ji 

runtime 

RUNTIMEF 

scalar 

fixed 

i . / . . ' 

returns Real Time Executive 
clock time (Section 8.) 

^ 

The scaling of the result of 
RUNTIMEF is implementation 
dependent 

Inextime 

(< labels) 
nextxme!f:; 

1 (<label>) 

scialer 
f ijxed 

< label> is the name of a pro- 
gram or task. The value re- 
turned is determined as fol- 
lows; 0 


a); If the specified process 
was scheduled with the 
REPEAT ENTRY option and 
has begun at least one 
cycle of execution, then 
the value is the time 
the next cycle will 
begin. 




















b) If the specified process 
was scheduled with the 
IN or AT phrase, and has , 
not yety begun execution, ' 
then the value is the 
time it will begin execu- 
tion. 

0 

o) otherwise, the value is 
equal -to the current 
, time (RUNTIME function). 

The scaling o^ the result * 
of NEXTIMEF is implementa- 
tion depe|^ent. 




// 



.MISCELLANEOUS FUNCTIONS (CONTINUED) 


Ijame, Argument 


Result Type 


Ccmments 


l^^^|L(a:,g) 


Same as a 


>) I 


01 may fee integer or scalar type. 
0 must^'^ be integer type. 

Tf ^ is integer type, the re- 
sult is an integer whose 
internal binary representation 
is jthat of a shifted left by 
3 bit locations . The signed 
nature of the integer ot is 
taken into account in an 
iTOpiementation dependent 
manner which depends upon the 
number systeiu and word size 
of the target computer. - 

If a is bit type, the result 
is a bit string containing 
the value of ot shifted left 
by 3 , bit locations % a is treated 
as an unsigned logical quantity. 
The size of the result is 
implementation dependent. 

Arrayed arguments produce m\^lti- 
ple invocations of the function, 
one for each array element - 
arrayness of arrayed arguments 
must match. 


SHR(<i« , 3 ) 


Same as a 


a may be integer or scalar type . 
3 must be integer type. 

Results are as defined for the 
SHL function except that all 
shifting occurs to the right. 


Arrayed arguments procuce 
multiple invocations of the 
function, one for each array 
element - arrayness of arrayed 
arguments must match. 


NORMALIZE (a) 

FIXED 

a must be FiXED type. The 

' . U-,,' ■ ■; 


scaling on a is reduced- until 
a is normalized. ‘ The scaling 

1 : - : ■ : \ 


of the result is undefined. 

NORMCOUNT (af 

INTEGER 

a must be FIXED type, phe re- 


• V . 

sult is the number of Ijeft 



shifts necessary to noi|malize a. 










CHAKACTSR FUNCTIONS 


^ • first argument Is character type ~ second argument 

is as indicated (any argtiment indicated as characjber 
. type may also be integer or scalar# Whereupon conver- 
sion to character type is implicitly assumed) 

• result type is as indicated 

• arrayed arguments produce multiple xnvocatidjii?5^,of 

the function# one for each array element - arraynesses 
of arrayed arguments must match 




r. Name # Argxments 

Result Type 

Comments 

INDEX (a# 3) 

integer 

3 is character type - if string 3 
appears in string a, index point- 
ing to the first character of 3 is 
returned; otherwise zero is re- 



turned 

LENGTHfa) 

integer 

returns length of character 


LJUST(a,$) 


RJUST(a,<8) 


TRIM (a) 


character 


character 


string 

3 is integer type - string ot is 
expanded to length B by padding 
on the right with blanks 
^3 ^ length (a) 

3 is integer type - string a is 
■''expanded to length 3 by padding 
on the left with blanks 
3 > length (a) ''' 


character 


leading and trailing blanks aije 
stripped from a 














o 

BIT PU^ICTIONS ' 

• : arguments are bit type 

O ' 

• result is bit type ^ 

C - 

• arrayed arguments produce multiple invocations 
of the function, one for each array ;,element - 

j arrayness of arrayed arguments must iqatch 

iQ - 

Name, Arguments 

Ilesult Type 

Comments 

XOR(a,0) 

bit 

0 

Result is Exclusive OR of a 
and 0. Length of r^ult is 
length of longer ^^gument. 
Shorter argument^'is left 
padded with bina^ zeros 
to length of long^ argu- 
ment. o 


ARRAY FUNCTIONS 

' ^ 0 fj 

• arguments < 
arbitrary 

• arguments < 

• result typ< 
unarrayed 

are n-dimensional arrays where n is 

are integer, scalar, or fixed type 
matches argument type and is 

Name, Parameters 

^.Comments 

MAX (a) 

' . ' rC'' ' 

: !L . 

maximum of al,^i element of a. 

If a is FIXED’ with a de,f ined 
scaling, then the result is defined 
to have the same scaling. 

MIN (a) ' , 

minimum of all elements of a. 

If a is FIXED, then the scaling of 
the result is undefined. ' 

PROD (a) 

product of all elements of a. 

IF ct is FIXED then the scaling of 
f the result is undefined. 

SUM (a) 

■) 

sum of all elements of a . 

If u is FIXED with a defined scal- 
ing then the scaling of the result 
IS the same. 













SIZE FUNCTION 


Name, Argument 


Comments 


. 


One of the following must hold: 

SIZE (a) 


• ; 

a is an un sub scripted arrayed 
variable with a one --dimension- 
al array specification - 
function returns length of 
array. q 

fi” 


• 

a is an ur: subscripted major 
structure with a multiple 
copy specification - 
function returns number of 
copies. 



• 

a is an unsubscripted 
structure terminal with a 
one-dimensional array speci- 
fication - function returns 
length of array. 



Result is or ^Integer type 















D. STANDARD CON\l!!IRSION FORMATS 

o 

In releatively limited circumstances HAL/S allows conversion 

between scalar, integer, bit and character types. The follow- 
ing rules govern such conversions. 

CONVERSIONS TO INTEGER TYPE: | 

O O 

i/ 

• A bit type is converted to intr^eger type by regarding it 
as the bit pattern of a signed integer of the desired 
precisi-on (halfwor,d Or fullwojrd) . Left padding with 

' binary zeros, or left truncation may occur. 

• A scalar type is converted to integer type by rounding 
to the nearest whole number. Overflow errors may occur 
if the absolute value of the scalar, type is too large 

to be represented as- aiv integer of the desired precision. 

• fixed type may be converted to an integer only by 

using the INTEGER conversion function. The specified 
scaling is performed and the resultant number is rounded 
to the nearest integer. q 

• A character type is convertible to integer type only 
if its value represents a signed whole number (e.g. 

•-604’f otherwise an error condition occurs. An error 
condition also occurs if the whole number is too large 
to' be represented as an integer of the desired precision. 

CONVERSIONS TO SCALAR TYPE : ' " 

• An integer type is converted direct!^ to scalar form. 
Depending on the implementation, and the precisions, ^ 
some decimal places of accuracy may be lost during conver- • 
sion. 

O ■ 

• A bit type is converted to scalar type by first converting 
it to double precision integer type according to the rule 
previously given, and then applying the integer to scalar 
conversion. 

• A character type is convertible to scalar type only if 
its value represents a legal scalar- or integer-valued 
literal (e.g. '-1.5E-7') . :See Section 2 . 3 . 3 for details of 
arithmetic literals. Other values cause error conditions 
to arise. 

• A fixed type may be converted to a scalar only by using 

the SCALAR conversion function. The specified scaling 
is perfofmed and the resultant number is then converted 
to internal scalar format. Some precision may be lost 
during conversion. ' ^ ^ ^ ^ ^ ^ ^ ^ « 
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CONVERSIONS TO FIXED TYPE: 

• A bit type is converted to fixed type by if ©gar ding 

I it as the bit pattern of a signad fraction of the desired 

■ precision. Left padding with binary zeros or left trun- 
cation may occur. Padding or truncation have the dffec^t 
of a scaling operation. ‘ ,, o 

f A scalar bypf is converted to fixed type by performing 
any specified scaling and then transforming’ the internal/ 
representation from scalar to fixed form. The value 
of the scaled number must lie between -1 and 1. 

• An integer type is converted to fixed type by performing 

; any specified scaling and then transforming the internal 

representation to fixed form. The value of the scaled 
number must lie between -1 and 1, , ^ 

• A character type is convertible to fixed type only if 

its value represents a signed number which will lie in the 
range -1 to 1 after scaling . <o 

CONVERSIONS TO BIT TYPE: 

• An integer or fixed type is converted to,, a bit string of 
maximum length . The value is the bit pattern of f he integer. 

• A scalar type is first converted to double precision 
integer type according to the rule already given, and the 
integer to bit conversion rules are then applied, 

• A character type is convertible to bit type only if its 
value is a string of 'I's and ^O's, ^nd blanks, (but not 

' all blanks) , otherwise an error condition arises. .The 
result of the conversion is always a maximum length bit 
string, irrespective of the argument type. If the argument 
has more then N bits, where N is the maximum aUpwable length 
of a bit operand, then only the N right-most are used. If 
the argument has fewer than N bits, the string is padded on 
the left with binary zeros. 




o 


CONVERSION TO CHARACTER TYPE; 

• An integer type is converted to the representation ? 


dddd 

-dddd 


(positive) 

(negative) 


where dddd represents an arbitrary number of decimal 
digits. Leading zeros are suppressed yielding a variable 
length result. 

A scalar type is converted to the representation : 


Jrfd.ddddE+dd 

-d.ddddE+dd 


(positive) 

(negative) 


(except scalar 0 is converted to 0.0). ' 

The number of decimal digits d in the fractional part and 
exponent are implementation and precision dependent. The 
digit to the left of the decimal point is non-zero. There 
are no imbedded blanks. Leading zeros in the exponent are 
not suppressed. The representation includes a leading /) 
blank (Jrf) if the scalar is positive. In all castes, the re- 
sult is fixed in length, 

A fixed is converted to chracters using the CHARACTER 
conversion function. After the specified scaling ,i.s performed, 
the conversion ts performed according to the same'^ rules as 
for scalars. \ 


• A bit type is converted, to a character string of 'I's and 
’ 0 ' s ,, corresponding to tile binary representation of the bit 
string argument. 



E. STANDARD EXTERNAL FORMATS 


Corresponding to each data t^ype there exists a "standard 
external format" for the representation of its values on 
sequential I/O files. In any implementation the standard 
external formal on output is fixed; on input the user has 
a certain flexibility in the format he can use.ji 

h ■ , —a 

OUTPUT FORMATS 


1. Integer Type ; ,£i 

• The value of an integer is represented by a 

string of decimal digits, preceded if it is negative 
by a - sign. Leading zeroes are suppressed. 


• The string of digits is right justified in a field 
of fixed width. The width depends on the implemen- 
tation, and on the precision of the integer. 


2 . Scalar Type ; 

• If the value of a scalar is positive it is represented 

by " 5 

)6d.dddddddE±dd 

where d represents a decimal digit. One non-zero 
digit appears before the decimal point. The numbers 
of digits in the fractional part and exponent are 
fixed, amd depend on the implementation and the 
precision of the scalar. Leading zeroes in the i 
exponent are not suppressed. The representation ' 
includes a leading blank . 

• A negative value has the same form except that a ~ sign 
precedes the first decimal digit. 

• If the value is exactly zero, it is represented as 

0 . 0 . 


• The representation of a scalar is contained in a field 
of fixed width. The width is dependent on the imple- 
mentation and the precision of the scalar. Justifica- 
tion is such that the decimal point occupies a fixed, 
precision dependent position in the field. 
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f*ixed Type 

• The value of a fixed is represented by a string of 
digits preceded by a decimal point and a minus sign 
if the number is negative. 

• The string of digits is contained in a field of fixed 
width. The width depends UE)on the implementation and 
the precision of the FIXED. Justification is per- 
formed so that the decimal point occupies a fixed 
position in the field. 

4. Bit Type (including BOOLEAN) ; ^ 

• There are two different representations of values of. 
bit variables. 

• The first representation consists of^ti string of 
binary idigits corresponding to the bit variable. Lead- 
ing bihar^ zeros are not suppressed. The field width 
is equal to the number of binary digits in the string 
plus an inserted blank following every fourth digit 

(to enhance readability). This form is not compatible 
.with the READ input (see Section 10.1.1). 

• In the alternate representation, the string of binary 
digits plus inserted blanks is enclosed in the apostro- 
phes. The field width is equal to the total of the 
number of digits, blanks and two apostrophes. 


5. character Type ; 

• There are two different representations of values 
of character variably , 

• The first representation merely consists of the 
string of characters comprising the value. The 
field width is equal to the number of characters 

in the string. This representation is not compatible 
with READ input (see Section 10,1.1). 


• In the alternate representation, the string of 
characters is enclosed in iipostrophes, and all 
internal apostrophes are converted to apostrophe 
pairs. The field width is equal to the total number 
of characters in the string, including added 
apostrophes. 

NOTE; The two alternate representations for bit and character 
types occur on paged ari|3 upaged output respectively, \ 


INPUT FORMATS 

1, Scalar/ Integer, and Fixed Types ; 

• There are three basic representations, whole-number, 
floating-point, and fraction, 

• The whole number representation' consists of a string 

of decimal digits preceded by an optional ' sign. The 
maximum number of digits allowed is implemeritation 
dependent. Conversion to mantissa-exponent form takes 
place for scalar types. 

, e l!:;p 

• The floating-point representation is either , 


147 


ddd.dddd 


or 


dddd.dddd 



tdd = 


where d is a decimal digit. Any number of digits 
is allowed in the mantissa to an implementation 
dependent maximum. The decimal , point may appear in 
any position. E,B, and H represent the., exponent 
digits to be pov;ers of 10,2 and 16 respectively . 

A choice of one is indicated. The maximum number of 
digits in the exponent is implementation dependent. 
For bit and integer types, the representation is 
rounded to the nearest integral value. For bit 
types the binary representation of the result is 
taken. 

♦ The floating-point representation may be prefixed 
by + of - signs to indicate the sign of the value. 
Without such prefix the value is positive.,;^ 

2. Character Type ; 

• The representation of character type is a string 
of characters from the HAL/S extended set enclosed 
in apostrophes . The number of characters may vary 
between zero (a "null string”) and an implementation 
dependent maximum. Within the string apostrophes 
must be represented by an apostrophe pair. 






F. COMPILE-TIME COHPUTATXCMS 


References are made in the text to expressions which must be 
computable at compile time. In particular the followings 
constructs make use of them: 

, ' 

• declaration of dinCensions ; ^ 

• initialization; 

e subscripting. ;■/ 

Subsets of arithmetic, ^bit, and character -.expressions are 
guaranteed to be computable at compile time. * 

ARTIHMETIC EXPRESSIONS (see Section 6.1.1) 


1. <arith exp>s of integ^ , scalar , and fixed type 
only can be computablelat compile time. 


The operators of such <arlth exp>s are limited to: 


o (multiply) 

/ \ 


@ (scaling) 

0@ (scaling) 

3. The <arith operand>s of such <arith exp>s may either 

be <number>s or unarrayed unsubscripted simple variables^ 
i>f integer, scalar, or fixed type. Such variables 
must previously have been declared, and^ initialized 
using the CONSTANT form. 

(See Section 3.8.) = 


see Section 4 . 5 


The following 

built-in 

functions are ’also legal: 

r? 

SIN 

EXP 

DATE 

COS 

LOG 

CLOCKTIKE 

TA^ 

SORT 

(1 

DATE ^d CLOCKTIME are only computed at compile %ime if 
they hppear in an <initialization> construct. 



BIT EXPRESSIONS (see Section 6.1.2) ^ ^ 


1. The operator^ which may appear in <bit exp>s computable 
at compile time are: 






& 


i 


The <bit operand>s of such <bit exp>s must be either 
<bit literal>s or unarrayed unsubscripted simple variables 
of bit type.. Such variables must previously have been 
declared^ and initialised using tlm CONST AN T f orm 

CHARACTER EXPRESSIONS (see Section 6.1.3) 


1. The catenation operator (||) only may appear in <char exp>s 

computable at compile time. ' 

“ .. 

2. T^e|<char operand>s of such <char exp>s must be either 
<'phar literal>s, <arith exp>s computable at compile time, 
or unarrayed unsubscripted simple Variables of character 
type. Such variables must previously have been declared, 
and initialized using the,, CONSTANT form. 

V. '■ " . . . -nV 


some ^ implementations , additional forms may also be computed 
compile time. They will not, however, be regarded as legal 
iii| contexts where compile time computability is enforced 
— ^mantically. „■ 
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4 

5 
4 
7 

A 

4 

10 

U 

IZ 

15 

14 

15 
14 
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lA 
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to 

tl 

Zt 

£5 

24 

ts 

t4 

t7 

tA 

t9 
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55 

54 

55 


54 
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Working Graromar 


COmO GRAHHAIt 


<C0HP1UT10H> VS * <C0MP1U IIST> o 

<COhPUt UST> V?« <BiOCK 0IF1H1T10H> 

I <COrtPllE UST> <D10CR DEFlHinoH> 

<AR1TM EXP>^/tt« <TERIi» 

I ♦ <nR«> 

I - <TERH> 

I <ARltH EXP> 4 <tERH> 

I <ARItH tXP> - <TERH> 

<TERH> ;:st <PRODUCT> 

I <PRODUCT> / <TERM> 

<PROOUCT> S!s <FACTOR> 

I <FACTOR> « <PROQUCT> 

I <FACTOR> . <PRODUCT> 

I <FACTOR> <PRODUCT> ° 

<FACTOR> t«a <PR1HARY> 

I <PR1HARY> <»«> <FACTOR> 

<«X> SSs tM» 

<PRE PRXMARY>°n= ( <ARITH EXP> » 

I <NUNDER> 

I <COHPOUND HUtlBER> 

<ARXTH-^C HEAO> <ARItH FUNO'" 

I <ARITH C0N¥> <SUDSCRXPT>“ 

<ARITH C0NV> 5 5» INTEGER „ 

I SCALAR 'V 

I VECTOR 
^ I MATRIX 
I FIXED 
I VECTORF 
I MATRIXF 

<PRIMARY> Sts <AR1TH VAR> 

..<FRE,PRIMARY> s;= <AR1TH FUNC MEAO> ( <CALL LIST> > 

<PRIHARY> 5 S3 <mooIFIEO ARITH FUNC> 

I <ARITH INLINE OEF> <OLOCK BODY> <Ct»OSING> S 
I <FRE PRIMARY^ ,)/ 

I <PRE PRIMARY^ <QUALIFIER> 

<0THER STATEMENT> Sis <ON PHRASE) <STATEMENT> 

% I <IF STATEMENTS 
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<IABEL OEFINXTX(M> MOTHER STATEHENT> 


<SUTEMFHT> ••••» <BASIC STATEMENTS 
I <OTHER STATEMENTS 


<ANT STATEMENTS ttx 


s 5STATEMENTS 
I 'tSLOCK OCFXNXTXONS 


<BASXC STATEMENTS 


* <LADEL DEFXNXTIONS <BASlC STATEMENTS . 

I <ASSXGNMcNT> S 

I EXXT ; C 

I EXXT <LABELS { 

I REPEAT 5 , 

I REPEAT <LABEtS";- \\ 

I GO TO <LABELS \ 

1 <CALL KEYS } 

I <CALL KEYS i <CALL tXSTS ) { 

I <CAU KEYS <ASSIC-NS ( <CALL ASSIGN LISTS ) { 

I <CALt KEYS ( <CALL LISTS ) <AS5IGNs ( <CALL ASSIGN LISTS ) ; 

I RETURN J 

i RETURN <EXPRESSIONs ; 

I <00 GROUP HEADS <END1NGS } 

J<READ KEYS 5 
I <REAO PHRASES } 

J <UflITE KEYS 5 
] <HRITE PHRASES ; 

I <F1LE EXPS = <EXPRESSIONS ; 

1 <ttARlA^> - = EXPS- i :v, 

I <HAIT KEYS FOR DEPENDENT 5 
I <MAIT KEYs <ARITH EXPs i 
1 <MAIT KEYS UNTIL <ARITH EXPS } 

I <HAIT KEYS FOR <BIT EXPS i 
I <TEGMINATORS { 

I <TERHINATORS <TERHINATE LISTS } q 

I UPDATE PRIORITY TO <ARITH EXPS ! A' 

I UPDATE PRIORITY <LABEU VARS TO <ARITH EXPS ; j 
I <SCHEDULE PHRASES ; <1 

I <SCHEDULE PHRASES <SCHEDULE CONTROLS ; 

I <SIGNAL CLAUSES J 
I SEND ERROR <SUBSCRIPTS ; 

I <0N CLAUSES J „ 

I <0N CLAUSES AND <SIGNAL CLAUSES ; o 

I OFF ERROR <SUBSCRIPT> i 
I <X MACRO NAMES (5 
I <X MACRO HEADS <X MACRO ARCS ) J 


<X macro HEADS ssa <X MACRO NAMES I 

"I <X MACRO HEADS <X MACRO ARCS , 

<X MACRO ARGS S5a <NAME VARS 
3 I <CONSTANTS 


■t0,IT PRIMS s;a <B1T VARS j 

I <LABEL VARS // 

I <EVENT VARS Q // 

I <BIT CONSTS . j 

I, ■( <B1T EXPs ) / 

I <M00IF1E0 BIT FUNCS / 

' I <BIT INLINE OEFS <BLOCK BODYS <OLOSINSS 
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9S I <iOMIT HE*0> <EXPRESSION> ) 

M I <BIT niNC HE*«» I CCAU «ST^? »([ 

W <BIT FUNC HEAO> SS« <BIT FUNO o „ 

95 \ BU <SUB OR qUAUnER> 

9* <BIT CAT> Jl« <BIT Ha«> ’ 

97 I <B1T CAT> <CAT> <BIT PR»i> 

98 I <»«)T> <BIT FRIH> CJ 

99 I <BXt CAt» <CAT> <NOT> <BIT PRI«> 

0 O ■ 

100 <BXT FACT0R> US <BIT CAT> 

101 I <BIT FACTORS' <AN0> <BXT CAT> ' 

X02 <BIT EXP> 8 U <BIT FACTORS 

103 I <BXT EXP> <0R> <8XT FACT0R> 

n li 

10 A <REUT10NAL OP>^?8* » j 

lOS ^ I <M0T> * 

104 I < r' : 

107 I > 

108 I < * 

X09 I, I > » 

110 1 <NOT> < 

111 I <NOT> > 

lU <C0MPARXS0N> ::s^<ARXTH EXP> ^RELATIONAL 0P> <ARX7H EXP> 

115 l°<CHAR EXP> CREUTIONAL OP> <)CHAR £XP> 

llA I <BIT CAT> <RELATXONAL OP> <0X1^ CAJ> 

115 I CSTRUCTURE EXP> ^RELATIONAL OP> ^STRUCTURE EXP> 

116 I <NANE EXP> <RELAT10NAL OP> <NAHE EXP> 

117 <RELATIONAL FACTOR> 855 <REL FR1N> 

118 1. <RELAT10NAL FAr.T0R> <ANO> <REL PR1M> 

119 <RELATIONAL EXP?> 8 8= ^relational FACT0R> 

120 I <RELATX0NAL-MP> <0R> <RELATI0MAL FACT0R> 


<REL PRX«> 


184 ^ <CHAR ^IH> 

125 .7 j) 

.11 


8= t <RELATX0NAL EXP> > 

\ <NOT> t cREUTXONAL EXP> 1 „ “ 

I <COMPARXSQN> . 

88= <CHAR VAR> ^ 

I <CHAR C0NST> 

I <H0DIP1ED CHAR FUNCX 

I <CHAR INLINE DEF> <BLOCK B0DT> <CL0SIN6> { 
I <CHAR FUNC MEA0> ( <CALL LIST> ) <, 

I ( <CHAR EXP> ) 


130 <CHAR FUNC HEAD> 8sa <CHAR FUNO 


<SU8 OR RUAL1FIER> 


I CHARACTER <SUS OR 00ALIFXER> 

88= <SUnSCRIPT> 

I <B1T <3UAHFI|R> 


<CHAR EXP> 88a <CHAR PR1M> 

I <CHAR EXP> <CAT> <CHAR PRXH> 

I <CHAR EXP> <CAT> <ARITH EXP> 

I <ARITH EXP> <CAT> <ARITH EXP> 
I XARITH EXP> <CAT> <CHAR PR1M>> 
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w 

140 

141 
14t 

143 

<i^’l44 

I4t 

144 

147 

140 

144 

150 

151 

152 

153 

154 

155 

154 

157 

o 

150 

154 

140 

141 

ue 

143 

144 

145 

144 

147 

160 

144 

170 

171 

172 

173 

174 

175 
174 

177 

170 

174 


V. 


<ASSZGM 1 EHT> 3 <yMUABLE> <> 1 > <EXME$SI 0 N> 

I' 4 :VARtABLE> * <ASSICKmNT> 

o 

<IE STATEHENT> SS* <If CUUSE> <STATE«EMT> 

I <TRUE PA»t> <STATEMENT> 

<TRUE RARt> : < 1 P CUUSE> <BASIC STATEHENT> ELSE 

CIAUSE> ::c <IF> <RELATIOHAL tXP> THEN 
I <IF> <BIT EXP> THEN 


<IF> !S« IF 

<00 CROUP HEAO> :s« 00 ! 

I 00 <FOR ilST>'>? 

I 00 <FOR LXST> <UHZLE CLAUSE> t 
I 00 <UHILE CLAUSES ; 

(00 CASE <ARXTH EXP> i 
I <CASE ELSE> <STATEHEHT> 

I <00 GROUP HEAO> <ANV STATEHENT> 

I <00 GROUP MEAO> <TEHPORARY STHT> 


<CASE EUSE> !!* DO CASE <ARXTH EXP> J ELSE 


<MHILE KEY> ^' i= WHILE 
I UNTIL 



<WH 1 LE CLi]USE> f s:; <HHILC KET> <BIT EXP> 

I <HH 1 LE KEV> <RELATXONAL EXP> 

<FOR LIST> !!= <FOR KEY> <ARITH EXP> <ITERATION CONTROL> 
I <FOR KEY> <ITERATION BOOV> o 

- - ■ - - ^ ■ 

<ITERATION BODV> 5 t 8 <ARITH EXP> 

r- I <ITERATION B 0 DY> , <ARXTH EXP> 

<ITERAT 10 N CONTROL> « != TO <AR 1 TH EXP> 

( TO <ARXTH EXP> BY <ARITH EXP> 

<FOR KEY> S 5 S FOR <ARITH VAR> s 

1 FOR TEMPORARY <IDENTIFIER> = 

<ENDING> ts- END ” 

I END <LABEL> 

1 <LABEL DEFIMXTION> <ENOING> 

< 0 N PHRASE> ;!S ON ERROR <SUBSCR 1 PT> 


< 0 N CLAUSE> ?!» ON ERROR <SUBSCRIPT> SYSTEM 
I ON ERROR <SU 0 SCR 1 PT> iBNORE 

<SI 5 NAL CLAUSE> 5 ?= SET <EVENT VAR> 

I RESET <EVENT VAR> 
t SIGNAC ^ EVENT VAR> 


<FILE EXP> SSs <FILE HEAD> » <ARITH EXP> ) 
<FILE HEAD> FIL^f <NUMBER> 

<CAU KEY> t != CALL <LADEL VAR> 
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160 

161 

162 

165 

164 

161 

166 
167 
166 

169 

190 

191 

192 

195 


I 


i<)7 

IW 

199 

200 
SOI 
SOS 

503 

504 

505 
S0« 
SO? 
SOS 

509 

510 
SU 

SIS 

513 

514 

515 
Sis 
E17 
SIS 
S19 
SSO 
881 


<CAU U8T> S8« <UST^XP> If 

\ <CAU "UST> . <UST 6XP> 

<C*LL ASSIGN LIST> 88s <VARIABLE> 

I <CALL ASSIGN L1ST> > <VARIASU> 

<EXPRESSION> t is <ARITH EXP> 

I <SIT 'EXP> o 

I <CHAR EXP> 

I -^STRUCTURE EXP> 

I <NAME EXP> I 

<STRUCTURE EXP> ii* ^STRUCTURE VAH> 

I <HODIFIEO STRUCT FUNC> ^ 

' { <STRUC INLINE C8F> <BL0CK B00Y> <CL0S1N6> ; 

-^STRUCT Fl^ HEAD> < <CAU L1ST> ) 

<STRUCT FUNC fiiSAGP ?8= <%|RUCT FUNC> 

<LIST EXP> iis <EXPRESSION> 

I <ARITH EXP> • <EXPRESSION> 

<VARIABLE> 5 ts <AR1TH VAR> 

I <STRUCTURE VAR> 

I <OIT VAR> 

I <EVENT VAR> 

I <SUBBIT HEAD> <VARIABLE> ) 
j <CHAR VAR> 

I <NAME KEY> I <NAHE VAR> 1 


<MAHE VAH> its <VARIABLE> 

I <LABEL VAR> 


<NAME EXP> 


I <M0D1FIED ARITH FUNC> 

I <M001FIED BIT FUNO 
I <MQDIF1E0 CHAR FUNO 
1 <M00IF1ED STRUCT FUNO 

!S <NAHE KEY> t <HAME VAR> ) 
I NULL 

I <NANE KEY> ( NOLL 1 


<NANE KEY> sis NAME 

<LABEL VAR> its <PREFIX> <LABEL> <SUBSCRIPT> 

-iMOOlFlEO ARITH FUNO !?= <prefiX> <N0 ARG ARITH FUNO <SUBSCRXPT> 
^MODIFIED BIT FUNO !i= <PREFIX> <N0 ARG BIT FUNC> <SUBSCRIPT> 
<M0DIFIE0 CHAR FUNO iis <PREF1X> <N0 ARG CHAR FUNO <SUBSCRlpT> 
<nODIFlED STRUCT FUNO ii* <|>REFIX> ^NO ARC STRUCT FUNO <SUdSCR1PT> 

■ .'O ' 

<STRUCTURE VAR> its <quAL STRUCT> <SUBSCRtPT> 

<ARtTH VAR> i i= <PREF1X> <ARlTH 1D> <S1^SCRIPT^^^^ 

<CHAR VAR> ! i=, <PREFIX> <CHAR l'D> <SUBSCR1PT> 

<BIT VAR> ! is <PREF1X> <B1T lO <SUBSCR1PT> " 


# 
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zzz 

<CVCHT V4H> <PREfIX> <2VENT X0> <SUeSCI?IPT> 

zzz 

<9U4L 8TRUCT> s i * <ST0UCTURC 10> 



1 <QU*L STRUCT> . <STftUCTURI: I0> 

225 

<PREFIX> s:» 


226 

1 <qUAL STRUCT> . 


227 

<SUBB1T KrA0> : ?« <SUeBlT KCY> <S(JBSCRIPT> ( 

226 

<SUBBIT KEV> SUBBXT^ 


229 

^SUBSCRIPr> <SUB HEAD> 1 


230 

1 <QUALIFIER> 


231 

I <♦> <NimSER> 


232 

1 <l> <ARITH VAR> 


233 

' 


236 

<SUB START> M* <•> ( 


235 

1 <♦&> ( S <FREC SPEO 

9 

236 

1 <*> ( a <PREC SPEO 

9 <SCALIW> » 

237 

1 <*> ( <8CALlte> , 


230 

1 <SUB HEAD> ; 


239 

I <SUB HEAD> : 


240 

1 <SUB HEAD> . 

O 


241 

<SUB HEA0> iU <SUB START> 


242 

« 1 <SUB START> <SUB> 


243 

<SUB> 8 8* <SUB EXP> 


244 

1 •* 


245 

1 <SUB RUN HEAD> <5UB EXP> 


240 

! <AP.ITH EXP> AT <SUB EXP> 


247 

<SUB RUN HEA0> f 8s <SUB EXP> TO 


240 

<SUB EXP> 8!= <ARITH EXP> 


249 

1 <• EXPRESSI0N> 


250 

<i EXPRESSI0N> 8:s « 


251 

1 <• EXPRESSI0N> « 

<TERH> 

252 

1 <• EXPRESSI0N> - 

<TERrH> 

253 

<=l> : S«S S 

- 

254 

<♦> :;= $ 


255 

<AND> 88S A 


256 

1 AND 


257 

<0R> 8t= 1 


250 

1 OR 


259 

<N0T> il~ - 


260 

” // 1 NOT 


261 

f -3 

<CAT?/8 :s llcv 
(/ 1 CAT 


262 


263 

<QUALIFIER> 8 != <♦> ( a <PREC SPEO 

) 


s 

i - : : ■ 
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0 


264 

265 



266 


269 

270 

271 

272 

273 

274 

275 

276 

277 
276 
279 
260 

261 

262 

263 

264 

265 

266 
267 

286 

269 

290 

291 

292 

293 

294 

295 

296 

297 
296 

299 

300 

301 

302 

303 

304 

305 

306 


I <♦> I <SCALIN6J/ I 
I <l> f a <PPEC SPEO^t <6CAtXNG> I 


<SCALE HEAD> tsa 6 

i a a 

<SCAIXH6> St* <SCAIE HEA0> <ARITH EXP> 
<6IT QUAUFZEP> J ?» <•> C a <RA0IX> I 


1 


o 


<RA0IX> : :« HEX 
I OCT 
I BIN 
I DEC " 

<BZT CONST HEA0> <RA0IX> 

I <RA0IX> ( <NUHBER> ) 

<BIT C0NST> ::s <BIT CONST HEAD> <CHAR STRIN6> 

I TRUE n 
I FALSE 
I ON 
I OFF 

<CHAR C0NST> tt~ <CHAR STRINO 

I CHAR ( <NUHBER> ) <CHAR STRlNe> 


<10 CONTROL^ :s* SKIP ( <AR1TH EXP> ) 

I TAB I <ARITH EXP> ) 

I COLUHN t <ARITH EXP> ) 

I LINE ( <ARITH EXP> ) 

! PAGE 1 <AHITH EXP> ) 

<REA0 PHRASE> ss* <REA0 KEV> <REA0 ARG> 

I <READ PKRASE> > <READ AR6> 


<HRITE PHRASE> t!= <MRITE KEY> <WRITE ARG> 

I <WRITE PHRASE> , <WRIVE ARG> 

<REA0 ARG> !!s <VAR1ABLE> 

I <10 CONTROL> 

I <READ FORMAT LIST> 

<VARIABLE IN> t:= <VARIABLE> IN 

<READ FORMAT LIST> s:= IN <CHAREXP> | 

I <VAR1ABLE IN> <CHAR EXP> 

I ( <CALL ASSIGN LIST> ) IN <CHAR EXP> 

<MRITE ARG> Sti; <EXPRESSION> 

I <10 CCNTROL> * 

I <MRITE FORMAT L1ST> 

<MRITE FORMAT LlST> ;;= IN <CHAR EXP> 

I <EXPRESSI0N IN> <CHAR EXP> 

I <WRITE FORMAT LIST BE6IN> <CHAR EXP> 

<EXPRES5I0M IM> S!= <EXPRESSION> IN 


<WRITE format LIST BEGIN> : <URITE FORMAT LIST HEAD> <EXPRESSION> e) IN 
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<MRITE FORHAT LIST HtAO> ( <EXPRESSJOH> > 

i I <HRXTE FORMAT LIST HEAO> <EXPRESSION> » 

<REAO KEY> : :« READ ( <ARI111 EXR> I , 

I REAOALL i <ARITH EXP> ) 


<HRXTE KEY> URXTE < <ARXTH EXP> ) 

<BLOCK DEFINITIONS it* <BLOCK -STMT> <BLOCK BOOY> <CL0SIN8> ; 

<BLOCK BOOTS ss« 

I <DECLARE CROUPS 
I <BLOCK BOOTS <ANY STATEMENTS 

<ARITH INLINE DEFS ::x FUNCTION <ARXTH SPECS ; 

I FUNCTION } 

<BIT INLINE OEFS it* FUNCTION <BIT SPECS { ^ \ 

<CHAR INLINE OEFS :ss rUNCTION <CHAR SPECS ; I 

<STRUC INLINE OEFS : :* FUNCTION <STRUCT SPECS ; ^ 

<BLOCIK STMTS ::s <»lOCK STMT TOPS ; 

Cl 

<BLOCK STMT TOPS :;s <BLOCK STMT TOPS ACCESS 
I <BLOCK STMT TOPS RIGID 
I <BLOCK STMT HEADS 
I <BLOCK STMT HEADS EXCLUSIVE 
I <BLOCK STMT HEADS REENTRANT 


<LA6El OEFTNITIONS ::s <LABELs : 

,<LABEL EXTERNALS sss <LABEL DEFINITIONS 
^ I <LABEL DEFINITIONS EXTERNAL 

<BLOCK STMT HEADS s;s <LABEL EXTERNALS PROGRAM 
I <LABEL EXTERNALS COMPOOL 
I <LABEL DEFINITIONS TASK 
I <LABEL ^SEFINITIONS UPDATE 
I UPDATE 'i\ 

I <FUNCTION NAMES 

I <FUNCTION NAMES <FUNC STMT BODYS 
I <PROCEDURE NAMES 
I <PROCEDURE NAMES <PROC STMT BODYS 

<FUNCTION NAMES ::= <IABEL EXTERNALS FUNCTION 

^PROCEDURE NAMES tt~ <LABEL EXTERNALS PROCEDURE 

<FUNC STMT BODYS ::= <PARAMETER LISTS 
I <TYPE SPECS 

I <PARAMETER LISTS <TYPE SPECS 

<PROC STMT BPJYS : := <PARAMETER LISTS 
1 <ASSIGN LISTS 

, , I <PARAMETER LISTS XASSIGN LISTS 

<parameter lists s;= <PARAMETER heads <IDENTIFIERS ) 
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350 
35X 

352 
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354 

355 

354 
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358 

359 
340 

34X 

342 

363 

344 

345 
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368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 
330 

361 

382 

383 

384 
365 



<ASSIGH iIST> ttx <A5SI6M> <PARAH6tt^ 
<A5SIGN> S t St ASSIGN 


CDECLARE EIEHENT> t tx <0ECURE STATEHENT> O 

I <REPUCE STHT> | 

I <STRUCtUREj 5THT> 

I EQUATE EXTERNAL <I0EHTXFIER> TO <VARIABIE> ; 

CREPLACE STNT> ttx REPLACE <REPIACE HE#^ BY <TEXT> 

<REPLACE HEA0> ssx <I0ENTIFIER> 

I <I0ENriFIER> C <ARC L1ST> ) 

<ARG LIST> stx <IDENtIFIER> 

I <ARG LIST> » <10EHT1FIER> 

<fENPCRARY STHT> t:r TEMPORARY <0ECLARE B0DY> t 

<0ECLARE STATEMENT> 5S5 DECLARE < DECLARE 900Y> t 

<DECLARE B0DY> St* <DECURATION LI5T> 

I <ATTRIBUTES> r <0ECLARATION LIST> 

<DECURAT10N LIST> t ?r <OECURATION> 

I <DCL LIST *> <DECLARATI0N> o 

. ^ : 

<0CL <DECLARATIDH UST> • 

<DECLARE GR0UP>%ts <DECLARE ELEMENT> 

\^| <DECLARE GR0UP> <DECLARE ELEMENT> 

<STRUCTURE STMT> S^^TRUCJURE <STRUCT STMT HEAD> <STRUCT STMT TAIL> 

<STRUCT STMT HEAO> Sts <ibEHTIFIER> t <LEVEL> 

I <IDENT1FIER> <MIH0R ATTR LlST> t <LEVFL> 

I <STRUCT STMT HEAD> <OECLARATION> » <IEVEL> 

<STRUCT STMT TAIL> Sts <DECLARATI0N>; 

<$TRUCT SPEO Sts <STRUCT TEMPtATE> <STRUCT SPEC B0DY> 

<STRUCT SPEC 60DY> s;= . STRUCTURE 

I XSTRUCT SPEC HEAp> <LITERAL EXP OR 8> ) 

<STRUCT SPEC HEAb> t:x - STRUCTURE C 

<DECLARATI0N> ssr <NAME ID> , 

I ><NAME I0> <ATTRIBUTES> 

<NAME 10> s:= <IOENTIFIER> 

I <I0ENnPIER> NAME 

<ATTRIBUTES> s:r <ARRAY SPEO <TYPE 1 MINOR ATTR> 

I <ARRAY SPEO 
I <tYPE & MINOR ATTR> 
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366 

<ARRAY SPiO it* <ARRAY MEA0> <LXTERA\. EXP OR »> I 

367 


1 FUNCTION ° 

366 


i PROCEDURE 

389 


1 PROGRAM ^ 

390 


1 T«K f 

391 

<ARRAY HCA0> 

-o Vi 

ft* array ( 

392 


r <ARRAY HEAD> <LITERAL EXP OR «> , 

393 

<TYPE\A MinOR ATTR> t <TYI»E SPEO 

394 


1 <TYPE SPEO <MIN0B ATTR USY> 

395 


1 <HIN0R ATTR LIST> 

396 

<TYPE SPEO t 

t» <5TR0CT SPEC> 

397 


1 <BIT SPEO 

396 


1 <CHAR SPEC> 

399 


1 <ARITH SPEO 

400 


1 EVENT 

401 

<BIt SPEO I t 

* BOOLEAN 

402 


1 BIT ( <LITERAL EXP OR «> ) 

403 

<CHAR SPEO : 

t- CHARACTER C <UTERAL 6XP OR »> ) 

404 

<ARIHI SPEO 

<PREC OR SCALE> 

405 

1 <SQ Oq NAHE> 

406 


1 <sq oq MAME> <PREC OR SCALED j, 

407 

<SQ Oq HAME> 

:s= < 00 UBLY qUAL NAME HEAD> ^LITERAL EXP OR »> 

406 


1 INTEGER 

409 


1 scA^iAR .V. ^ 

410 


i VECtOR 

411 


1 MATRIX 

412 


1 FIXED 

413 


1 VECTORF 

414 


1 MATRIXF 

415 

<OOUBLY qUAL NAME HEA0> it= VECTOR ( 

416 


1 MATRIX ( <LITERAL EXP OR »»> , 

417 


1 VECTORF ( 

4X6 


1 MATRIXF t <LITERAL EXP OR «> , 

419 

<PREC OR SCALE> t := <SCALING> 

420 


1 <PREC SPEO ° 

421 


1 <PREC SPEO <SCAHNG> 

422 

<tITERAL EXP OR R> ? <ARITH EXP> 

423 


1 * 

424 

<PREC SPEO : 

ss SINGLE 

425 


1 DOUBLE 

426 

<ftIN0R ATTR LI5T> : <liIN0R ATTRIBUTE> 

427 


1 <M1N0R ATTR lISt> <MIN0R ATTRIBUTE> 


428 <mNOR ATTRIBUTE> <MINOR ATTRIBUTE X> 

429 I <HINOR ATTRIBUTE 2> 

430 <MIN0R ATTRIBUTE 1>::= STATIC 

431 I AUTOMATIC 


ORlGiNAL ?AQE IS 
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43e 

433 

434 

435 

436 

437 
436 

439 

440 

441 

442 

443 

444 

445 

446 

447 

446 

449 

450 

451 

452 

453 

454 

455 

456 

457 
456 

459 

460 

461 

462 

463 

464 

465 

466 

467 
466 

469 

470 

471 

472 

474 

475 

476 


OCNSC 

^ I 4UGNC0 
t ACCESS 

I COCK C <UTERAt EXP OR P> > 

I RENOTE 
S RIGID 

I <1NIT/CWST HEAO> <REPEATED C0HSTANT> ) 

I <INrr/CQNST HEAD> • I . 

I UTCHEO J) 

I MONHAL I <LEVEL> I / 

<MINOR ATTRIBUTE 2> ? s* <RANGE HEAO> <ARZTH EXP> I 

<RANSE MEAD> Us RANGE C 

I <RANGE HEAO> <ARITf; EXP> TO 

<INIT/C0NST MEA3> U= INITIAL ( 

I CONSTAf4T t 

I <1MIT/C0NST HEAD> <REPEATEO CdHSTANT> . 

<REPEATED CONSTA.NT> :u <EXFRESSION> 

I <REPEAT HEA0> <VARIABLE> 

I <RfcPEAT HEAO> <COSSTANT> 

I <NESTEO REPEAT KEAO> <REPEATED CONSTANT> I 
I <REPEAT HEAD> 

<REPEAT HEAD> ;:= <ARITH EXP> • 

<NESTE0 REPEAT'ilEAO> vss <RCPEAT He/^> ( 

I <NISTE0 REPEAT HEA0> <R|PIATED CaNSTANT> 

<CONSTANT> !!- <NUKBER> 

I <COMPOUND NUMBER> 

I <B1T C0NST> 

I <CHAR CONST> 

<NUf1BER>- us <SIHPLE NUMDER> 

I <LEVEL> 

<CtOSIh’G> u= CLOSE V 

I CLOSE <LABEL> 

I <LABEL DEFINtTION> <CLOSING> 

<TERMINATOR> Sts terminate , , 

I CANCEL , ^i,v 

<TERMINATE LIS^; Sts <laBEL VAR> 

I <TERMINATE LIST> , < LABEL VAR> 


<MA1T KEY> Sts WAIT 

<SCHEDULE HEAD> ts= SCHEDULE <LABELVAR> 

( <SCHEDULE HEAD> AT <ARITH «XP> 

I <SCHEDULE HEA0> IN <ARITH EXP> 

I <SCHE0ULE HEAD> ON <BIT EXP> 

<SCHEDULE PMRASE> sss <SCHEDULE HEA0> 

I <SCHE0ULE HEAD> PRIORITY ( <ARITH EXP> ) 
I <SCHEDULE PHRASE> DEPENDENT 
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477 

476 

479 

<SCHCDULE 

C0NTR0L> :*» <9TOPPIHO> 

1 <TiniN6> 

1 <TXniN6> <ST0PPXN6> 

460 

461 

462 

<TI«ING> : 

is <REPEAT> EVERY <ARXTH EXP> 
1 <REPEAT> AFTER <ARXTH EXP> 
1 <REPEAT> 

463 

<REPtAT> 2 

is , REPEAT 

464 

485 

<5T0PPINS> 

iis <NHXIE KEY> <ARXTH EXP> 
1 <HHXLE KEY> <BXT EXP> 
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H. SUMMARY OF OPERATQi| 

This section contains a series of tables which" explicitly 
summarize the possible arithmetic, bit, character, and conditional 
operators used in forming expressions in the HAL/S Language. 

The information found in this appendix has been abstracted 
from chapter 6 of this specification. 
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H-1 



H.l ARITHMETIC OPERATORS^ 


OPSAATORS 

NAME 


1 

o> 



/ PREOSDSNCB 

L=-= 

FORM 

COMMENTS 




Exponentiation 

. 1^’ 

Product 

a 

cross Product 

t 

II ^ 




x**x 




Division 

s 

Addition 

6 

Subtraction 


’(( 

• 

' • ■ . . i 



Ordinary axponontiatiori 
Ropaatad ^altlp licit ion 
Identity matrix 
napaatod of invaraa 

7ranspota of matrix 


matrix^matrix product 
matrix-vactor product 
voctor-matrix product 
outar product 

scalar or integer product 
vith matrtx/vector 

scalar or integer product 
with scalar or integer 


cross product of two 3-vectots 


dot product of two voofeors 


■ ■ o •' ■■ -■ ■■ 

division Of left-hand tetm 
by scalar or integer 


.Algebraic addition or 
subtractioni binary plus 
‘and minus 


The following abbreviations apply s 

i * positive integer literal 

. ^ Scalar, integer, or fixed 

' ■' m * matrix ' 

V “ vector . 


*Sote that this table contains information found in Section 6*1.1 

H-2 


ORIGINAL RAGE ir 
OF POOR QUALITY 


ID 





























H.2 CHARACTER OPERATQJl 


conc«ttn*tion j | | j sulq ^1 raiiuit 


*Note that thxs table coritai^s information found in Section 6.1.3 

^ (= : i -ft 

V , . 0 ■ ■ 


H.3 BIT OPERATORS^ 


OPEHATOBS 

NM4S 

aiT OPERATOR 
PRBCBDBNCE 

FORM 

COWIENTS » 


concatenation 


logical product 


logical aum 


B||B I 111101 


lUOlOlO 


BS;B Parallel operation bit by bit 


b|B 1 Parallel operation bit by bit 


NOT j 


logical 

compleiftent 


Highest implieq 
by syntax I 


Parallel operation bit by bit i 


^he foil wing abbreviations apply; 

B » bit string or boolean o 


thatL thx^ table contains information found in Section 6. !• 2 
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H,4 GONDITICMJAt AND EVENT OPERATORS* 


Idgical product 


al sum 


C4C Trua if both true 

C AND C 


Trua if aithar ”C** ia trua 


logical 

eomplasumt 


^Highaat 
impliad by, 
syntax 


Operand 


Tha following abbreviations apply: 

•*€*• • any conditional operand. 


*Note that this table contains information found in Sections 6,2 
and 6*3, • V 


H, 5 COMPARISON OPERATORS* 


OPERATOR 


COI«LMENTS 



A > B 

A >- 

B 

A < B 

A< * 

B 

A -> 

B 

i A '< 

B 

A*B 


A 

B 


magnitude comparsions : apply only to 
^ unarrayed scalar and integer data A and B. 


■ ■ ■ ■■■ V ■ . ■■ - ■ 

‘ equdiity/ineguality for general data A and B* 


*Note that this table contains information found in Section 6.2 
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% MACROS 




The specific details of l-macros operation as well as 
the % macros available are implementation dependent. A 
generic description of % macro syntax can be found in 
Section 11.2 of this document* 


Individual implementations of Jbhe HAL/S language 
may contain %macro capalsilities. The documentation for ' 
each implementation (such as a User's Manual) will contain 
the detailed descr^^ptions of the available % macros. 
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I) 





INDEX 


c 


ACCESS 

to NAME variables 
active process 
ALIGNED 




AND 


apostrophe 

argument type summary Cchart) 

arithmetic comparisoh 
syntaj^ diagram #32 
legal arithmetic comparisons 

arithmltic conversion function 
syntax diagram #39 


<ar xth <jonversion|^ 

arithmetic exprej^sions 
syntaXj^-^iagri 

<jarith exp> 


syntax diagram #24 
in subscript 
in type spec 

<arith exp># 

<arith inline> 

arithmetic literals 

<arith %-macro|| 

<arith operands 

syntax diagram #25 

arithmetic operand 
arith % -macro 

syntax diagram #25s 


Index-1 


3- 14 to 3-21 

4- 15, 4-17> 4-19 

11-18,11-27 

8-2 

o 

4-10, 4-11, 4-15 
,4-17, 4-19, 4-20 
11-21, 11-27 

6-8, 6-9 
6-14, 6-22 

4- 7 
6-38 

6-16 

6-17 

6-27, 6-38 

6-6, 6-29 
6-3 

6-3, 6-16, 7-22 
8-11 
6-3 

5- 12 

4-22, 4-23 
4-27, 6-29, 6-4 

11-4, 11-8 
2-8 

11 - 6 , 11-8 

6- 3, 6-6 

11-8 



<arith var> 


ARRAY 



array dimension 
array properties of expressions 
array specification 


<array sub> 


0 


array subscripts 

syntax diagram #22 

Array Subscripting 


arrayed <comparison> 
arrayed infix operations 
arrayed operand comparison 


Assignment statements 
event variables 
of NAME identifiers 
ASSIGN 

a^igno parameter 


psignment 


assignment statement ^ 
syntax diagram #46 

asterisk, use of 


o 






5-16 

4- fs, 4-16 

5- 17 

6 - 13 '^ 

4-16, 4-19, 

4- 281, 4-29, 

5- 7, 5-8, 5- 

5- 11 

4- 2, 5-7, 5 

7- 10 

6- 19, 6-18 

O 

6- 13 
6-21 

5- 17, 5-19 

7- 5 

6- 23, 6-25 

,V £! 

11-19 

3- 16, 7-9, 

7- 10 
7-1 
7-5 

O' 

4- 19, 4-24, 
4-27, 4-30, 

11-19 - 

,c> - . ’ 

2-12 


Index- 2 


4- 20 

5- 17 

14 

14 


7-10 


4- 25 .. 

5- 11 

o 


»T <arith exp> 



AT-partition 

5-12, 

5-15 

5-13, 

<attr|.bute8> _ 

factored <attribute8> 

4-14 

4-14 


AUTOMATIC 

i 

3-18, 

basic Statement 

syntax diagram 144 

7-2 


<basic statement> 

7-25 


BIT ■ 

0 „ 

4-24, 

11-4 

4-29, 

bit argument length 

6-25 


bit assignments 

7-7 


bit comparisoi^ " 

syntax diagram #33 

6-18 

,// 

// 


bit conversion function 
syntax diagram #40 

6-3l 


<bit conversion> 

6-9 


bit expression 

syntax diagram #26 

6-8 


<bit exp> 

4-29, 

6-18, 

7-18, 

6-8, 

6- 35, 

7- 19 

bit expression length 

7-14 


<bit inline> 

11-4, 

11-9 

bit literals 

2-9 


<bit literal> 

6-9, 

6-10 


Index-3 









1 : ■ „ 
t 

bit operand 

syntax diagi^fun #27 
bit inline 
bit%-macro 

^ syntax diagram #27s 
bit operator precedence 

a o 

<bit %-macro> .. 
<bit-pseudo var> 


o 

'■j 

6-9 

11-9 

6-9 

11-6, li-9 
6-36, 7-7 



<bit var> 

BIN 

@BIN 

blanks 

Block delimiting statements 

block name uniqueness 

Block Templates 

syntax diagram #6 


6-10 , 6-9 

2-9, 6-32 

6-33, 6-35 

2- 14, ^tJa-21 

3- 13 


3-23 

3-13 

3-11 



BNF Greunmar of HAL/S 


Appendix G 

1 } 


BOOLEAN 


4-22, 4-24, 4-29 
11-4 


built-in functions 6-''2¥j^'ll-l 

K 

built-in function neunes o 2-6 

^8 ■ ■ 

built-in function parameters 6-25 

BY 7-23 


I 

I 


Index^4 


ORIGINAL i^AGE V 
OF POOR QUALITY 


o 




CALL Sta 

syntax diagram #47 
with NAMEy 

syntax '^'diagram #4 7s 

call-by-re£erence 

call-by-value 

CANCEL statement 

syntax diagram #58 

cancellation 

CAT 

catenatio^^^ 

channels 

HAL/S (^aracter set 


-s?* 


7-9, 7-10 
7-9 

11-32 


6-2% 

7^10 

6-25, 

7-10 

8-9 


8-8 


8-6, ' 

00 

1 

% 

00 

1 

00 

o 6-8, 

6-9, 6-11 


6-11 

10-1 

2-4 


CHAR 

O 

HI 

1 


CHARACTER 

1 1 

4-29, 

7-10, 

character argument length 

6-25 


character comparison 
syntax diagram #34 

o 

6-19 


character conversion function 
syntax diagram #41 

6-34 


<char conversion> 

6-12 


charac^ter expression 
1 syntax diagram #28 



^ character expression length 
’ <char exp> 

7-14 


4-29, 

6-33 

6-11, 

character initialization 

4-29 


<char inline> 

11-5, 

11-10 

cha^rac ter length 

4-24 


0 character literal - 

2-10, 

4-7 

<character literal> 

2-10, 

6-12 

; <character %-macro> 

11-7, 

11-10 

index-5 




6 


o 




character errand 
syntax diagram #29 
char inline 
' char l-macro 

syntax diagram #298 

character operator precedence 

character string 

■ character type 

<ch|r var> ^ 

CLOSE Statement 

syntax diagram #10 

CLOSE 

closing 

<closing> 

code blocks 

colon, use of 

COLUMN 

conuna, use of 

comments (imbedded) 

<comparison> 

<compilation> 

CdSponent Subscripting 

component subscripts 
syntax diagram #22 

<Component sub> 


Index -6 


C-12 

11-10 

6- 15 
6-11 
4-24 
6-12, 
3-22 

7- 13, 
3-4 

3-13, 

3- 13 

4- 11, 

10-3, 

10-9 

4-7, 

10-6 

2- 14 

6- 14, 

3- 2, 

4- 2, 

7- 7, 

6-12 





7-7 

o 

7-14 

3-22 

5- 14, 9-4 
10-7, 10-8 

-11, 6-12 

6 - 21 

1 - 23 , 7-9 

o 

i-7, 6-36 
’-10, 7-11 

3-9, 6-17 


COMPOOL 


3-2, 3-11 

COMPOOL block 

syntax diagram IS 


3-13, °3-22^ 
3-10 

<conpool block> 


4-19 

COMPOOL block template 


3-11 

<compool header > 


3-10 

compool header statement 


" 3-14 

compool modules 


3-1 

<compool template> 


4-19 

<condition> 


6- 1, 6-15, 7-4 

7- 18, 7-21, 7-23 

conditional expression 
syntax diagram #30 

-- 

6-1 

6-14 

conditional operand 
syntauc diagram #31 

■ 0 

6-15 

<conditional operand> 


6-14 

CONSTANT 


4-26 

conversion 


6-25 

conversion functions 

summary of argument types 


6-38 

cyclic execution 


8-4, 8-6 

Data- declarative attributes 
syntax diagreun #15 

H '■ 

o 

4-15 

Jl 

dita declarative <attributes> " 


4-14 

Data Manipulation “ 


6-1 


Index-? 



11-19 


Data NAME identifiers ^ ^ 

11-19 

Data referencing ^ 

<P 


Data Sharing and the UPDATE Block 

8rrl8 

data types 

1-2 

DEC 

2-9, 6-33 

@DEC 

O 

6-34,6-33, 6-^35 

DECLARE Statement 

4-14 

syntax diagram #14 
with NAME 


syntax diagram #14 s 

11 - 17 ^, 

<declare statement> 

4-3, ii-42 

declare group 

°3-4, 3-6, 4-i/ 

syntax diagram #11'^ 
with EQUATE 

4-3 J/' 

syntax diagram #115 

11-42 

<declare group> 

3-12, 5-2 

Declarations of Temporaries 

11^14 

o 

Declaration of NAME temporaries 

11-24 

DENSE/ALIGNED 

4-17, 11-18 

DENSE 

4-10, 4-11, 4-15 
4-19, 4-20, 7-10 
7-11, 7-12, 11-18 
11-21, 11-22 

DEPENDENT 

8-6, 8-11 

dependent processes 

8-2 

DO 

11-13 

DO statement 

7-16 

syntax diagram #50 


<do statement> 

7-15, 7-24 

DO GASie statement o 

syntax diagram^. #51 

7-17 

DO... END Statement group 

7-15 


syntax diag^ram #49 


Index-8 


o 



DO.. .END 


DO... END Statement 
„ TEMPORARY statement 

syntax diaqraifl #49s 

% • " 

DO FOR 'i. 

Discrete i>0 FjQR Statement 
syntax diagram #53 

discrete DO FOR 

with loop TEMPORARY variable index 
syntax di agram " # 5 4s 

Q ' V ' • • 

iterative, DO FQiR,jj ^ 

DO WHILE and UNTIL statements 
syntax diagram #52 



7^24^ 7*»2S, 1 ^%%- 
11*16 — 

n-13 

11-16 

7-20 

11-15 

7-22 

7-18 


DO UNTIL 
1?0 WHILE 
DOUBLE ^ 

double ’ precis ion 
double quotes 


7-19 

11-30 

4-22, 4-23, 6-39 
7-6 

6—16 © 

4-5 


ELSE 7-3, 7-4, 7-17 

o dangling ELSE « 7-4 

g - 

END 7-24 o 

. tj END statement 7-24 

syntax diagram #55 

<end statement> 7-15, 7-24 



Index- 9 


ORIGINAL MGE \t 
OF POOR QUAU^ 


EQUATE Statement 

syntax diagram #80 

errors 

system-defined 

user-defined 

error code 

error environments 

error groups 

error number^ ' 

Error precedence (chart) 
<error spec> 

Error Recovery 

Error Recovery Executive (ERE) 
EVENT 


11-40 

11-40 


9-i; 9-5, 9-7 


g^i 

9-1 


9-7 

9-6 


9-3, 

9-4, 9-5 

1-2, 

7-1 

9-4, 

9-7 

8-8, 9-1 

4-21, 

4-22, t 


event change point 
Event Control 


8-5, 8-7, 8-8 
8-14 

8-14 


isevent expression 
\ syntax diagram #36 


6-1 

6-22 


<event exp> 

\ 

6-22, 

8-12 

event infix operator precedence 

\ 

6-22, 

6-23 

event operand 

syntax diagram #57 


6-23 


<event operand > 


6-22 


<event var> 
latched 
unlatched 


6-JO 

8-15 

8-15 



index-10 


8>6 


EVERY <arith exp> 

't, 


8-6 

EXCLUSIVE 


3-16 to 3-21 

executable statements ^ 


7-1 

EXIT statement 

syntax diagram 156 

-.■j 

7-25 

EXIT 


7-26 

explicit conversion functions 


6-31, 6-27, 
6-32, 6-34 
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